一、内存泄漏的产生原因（原理层面）资源未正确释放动态分配的内存未调用释放接口（如C/C++中malloc后未free）。持有资源的对象未正确关闭（如文件句柄、数据库连接、网络Socket未调用close()）。对象引用链异常强引用循环：对象A引用对象B，B反向引用A，导致垃圾回收器（GC）无法识别可回收对象（典型如Java中未断开的双向链表引用）。长生命周期引用短生命周期对象：如静态变量持有Activity上下文，导致Activity无法随页面跳转释放（Android常见场景）。资源管理机制缺陷容器类未正确移除元素：如HashMap中存储的对象已失效，但未调用remove()移除键值对。事件监...

继4月份二面挂，5月份一面挂之后，我现在的这第51次流程又开始了又复活了！加上日常实习，暑期实习和春秋招这是我第8次面试快手了 快手也是给我机会最多的公司诸葛亮七擒七纵 我也被放虎归山了4次以上这次其实也很难成功但是也放手一搏吧 毕竟也是我尽力了的证明不管成功和失败 我都做到了不留遗憾 无愧于心。

也是非常经典的问题，一些简单的八股，进程和线程的区别，然后输入url以后它整个的过程，非常非常的简单，然后他问了一个内存泄露的场景，然后我也回答了一下多线程多进程啥的，然后又问了一下我平时的一些科研项目主要做的是什么东西，然后又问了一下我的工作场景，测试策略，测试用例的编写手段，以及与同事的交流手段，还有就是自动化测试你参与了哪些工作，然后什么时候要进行自动化测试以及这个自动化测试它的优缺点，为什么你不手动执行，而要改这个自动化的脚本，难道不会很麻烦吗，然后后续的职业规划，然后为什么到现在这个时间节点了还在找工作，然后出了一道中等的手撕，也是hot100里边的比较简单，然后我反问了一下，这个是之前有人毁约的。岗位呢还是新增的需求呢？他回答是新增的需求，然后问了一下工作地点，然后问了一下这个相关的业务，大概就这样，整体来说还是很简单的，问了一下总共有headcount，他说只有一个，然后招人

一、自身链路接口测试重点自身链路接口测试主要关注系统内部逻辑的正确性、性能和稳定性，确保接口按预期处理请求并返回正确结果。测试点包括：功能验证：正常/异常输入处理、业务逻辑正确性、状态码和返回数据格式。性能测试：响应时间、吞吐量、并发能力及资源消耗。异常场景：超时、重试、幂等性、数据一致性及错误恢复机制。安全与兼容性：认证授权、数据加密、防攻击能力，以及多版本/多客户端兼容性。典型测试场景如：模拟高并发请求验证系统稳定性、故意传递非法数据测试容错能力、重复提交请求检查幂等性等。二、外部依赖接口测试重点外部依赖测试需确保系统能正确处理第三方服务的交互，重点关注契约合规性和容错能力。测试点包括：契...

一般是一些被鸽了offer的中厂的机会和一些1-3年经验的社招机会但是昨天进行了毕业照拍摄 今天进行了毕业典礼理论的倒计时变成了真实的现状 即将就要离开校园 快没有一种心态去应对和准备了面试官问我为何叹气 因为我面对的是困难的技术提问和我迷茫的人生不想说的再见 说不出的毕业快乐  因为那不是真正的快乐还是言归正传融360 一面挂 应该是招到人了微店 一面泡着 应该是有人接offer了 所以暂时不推进哈啰_武汉 薪资太低 所以拒绝面试了 加上没时间面试欢聚 二面完成暂时没有继续推进360 今天下午一面再就没了 这段在校的时间 是人生最美好的时间 但是也备受煎熬 因为前方啊 没有方向……

这个问题的话基本上也是根据业务场景深挖，然后一些性能场景，如果有问题 怎么根因分析，然后问了一个八股问题，就是full gc和young gc的问题，这个jvm的我都没背多少，然后被问到了，然后我说了一下常见的垃圾回收机制，然后还问了一下怎么sql分页进行查询。这一块儿我也不知道，然后的话问了一下怎么对风控场景进行校验，然后如果说对线上问题的解决，然后定时巡检做了哪些工作，基本上还是一些业务场景的询问，然后八股相对来说少一些，基本上还是问你的简历，然后有一些前端知识的了解什么的，然后还问了一下怎么做一些场景设计，如果说遇到一些消息丢失，消息重复，消息有序性的这些业务场景的校验。然后问我会不会go，这个go确实不会。然后问了一下我的期望薪资，然后我说了一下我的期望，最后我反问，问了一下。电商业务的战略规划以及测试的空缺需求，以及稳定性怎么样，然后他也问了一下我能不能接受广州。最后我还是表达了一下我的意向，还是挺想去的。还问了下装饰器 印象深刻的 有成就感的bug  能接受的工作强度

虽然加班严重 讲求奉献虽然公积金5%虽然很多办公地点都在郊区虽然od招聘负面新闻曝光但西电南邮杭电重邮深大的著名学校里面 能力一般的同学也可以拿华为当做自己的备胎 有了一份保底和希望但就凭这一句遥遥领先 敢为人先 追求卓越 中华有为的宣言成为妇孺皆知 老少咸宜的民族企业加入华为就像是 为国为民 大义凛然的英雄豪杰加入华为就像是 毫不为己 专门利人的道德楷模加入华为就可以 把自己的热血泼洒在祖国最需要的地方加入华为就可以 立鸿鹄志，做奋斗者，为中国梦的实现贡献自己的青春力量和青春智慧总结来看如果能加入华为 这辈子就有了！

一、主从库读写测试步骤1. 环境准备：- 搭建主从架构（1主1从或多从），确保主从复制正常（可通过 SHOW SLAVE STATUS 查看IO和SQL线程状态）。- 主库配置 server-id=1 ，从库配置 server-id=2 ，主库开启二进制日志（ log-bin ）。2. 读写测试核心操作：- 写操作测试：在主库执行增删改（如 INSERT/UPDATE/DELETE ），观察从库数据是否同步（可通过定时查询或触发器验证）。- 读操作测试：在从库执行查询（如 SELECT ），确认数据与主库一致，同时测试从库负载能力（可通过压测工具如 sysbench 模拟并发读）。- 异常场景测试：- 主库宕机：验证从库是否可切换为读写模式（需手动或通过中间件如MHA自动切换）。- 网络延迟：模拟主从网络波动，观察数据同步延迟（ Seconds_Behind_Master 参数）。3. 关键指标记录：- 同步延迟时间、读写性能差异、高并发下的一致性表现。二、主从复制原理1. 核心机制（基于二进制日志）：- 主库（Master）：将数据变更记录到二进制日志（Binlog），包括DDL和DML操作。- 从库（Slave）：通过两个线程实现复制：- IO线程：连接主库，读取Binlog并写入本地中继日志（Relay Log）。- SQL线程：解析中继日志，在从库执行相同操作，实现数据同步。2. 复制模式（3种）：- 异步复制：主库写入Binlog后立即返回，不等待从库确认（性能高，一致性差）。- 半同步复制：主库等待至少一个从库确认接收Binlog后返回（性能和一致性平衡）。- 全同步复制：主库等待所有从库确认后返回（一致性高，性能低）。3. 常见问题与面试考点：- 主从延迟：高并发下从库同步慢，解决方案：升级硬件、读写分离、分库分表。- 数据一致性：异步复制可能丢失数据，可通过半同步或中间件（如Canal）弥补。- 切换与故障恢复：手动切换主从时需锁定主库（ FLUSH TABLES WITH READ LOCK ），避免数据不一致。三、面试场景- 结合场景说优势：主从架构用于读写分离，减轻主库压力，适合读多写少场景（如电商商品页查询）。- 提扩展知识：主从是分布式基础，可延伸到集群架构（如MGR、InnoDB Cluster）或中间件（MyCat、ShardingSphere）。

1. 基本路径表达式node选取当前节点的所有子节点（包括元素、文本、属性等）。bookstore/book//node从任意位置选取节点（全局搜索）。//book.选取当前节点。...选取当前节点的父节点。book/..@attribute选取属性节点（@后接属性名）。book/@category2. 谓语（Predicates）用于筛选节点，用方括号 [] 包裹条件：bookstore/book[1]选取第一个 <book>节点（XPath 索引从 1 开始）。bookstore/book[last()]选取最后一个 <book> 节点。bookstore/book...

懒加载定义：按需加载资源，仅当用户需要时才动态加载，避免一次性加载全部内容。核心场景：图片懒加载：滚动到图片位置时才加载真实图片（如淘宝商品列表）。组件/JS懒加载：SPA路由切换时加载对应页面JS（如React的React.lazy）。数据懒加载：分页加载表格数据（如微博下拉加载更多）。实现方式：传统：通过IntersectionObserver监听元素是否进入视口。现代：HTML原生属性loading="lazy"（Chrome 76+支持）。优点：提升首屏加载速度（减少初始资源请求）。节省用户流量（仅加载可见内容）。降低服务器压力。缺点：实现不当可能导致图片“闪现”（...

一、前端Bug定位：从控制台到代码调试场景1：页面白屏/渲染异常控制台查错：按F12打开Chrome DevTools，查看“Console”面板JS报错（如Uncaught TypeError）。例子：报错“Cannot read properties of null (reading 'appendChild')”，定位到JS中操作空DOM元素，如图片未加载时提前操作img节点。网络抓包：切到“Network”面板，刷新页面查看资源加载状态： 若CSS/JS报404，检查CDN路径是否正确（如版本号写错v=1.0写成v=10）；若图片加载慢，查看Size列（如未压缩的原图导致加载超时）。断...

今天面试官问我的 没回答上来 总结一下前端性能测试核心知识点与实操详解一、用户感知与性能维度拆解1. 用户核心关注点是否正在发生：输入URL后服务器响应速度（如输入网址后浏览器是否立即显示加载动画）。是否有用：首屏核心内容是否快速呈现（如电商首页的轮播图、商品列表）。示例测试：打开淘宝首页，用秒表计时从点击链接到首屏商品卡片出现的时间，对比不同网络环境（4G/WiFi）的差异。2. 性能测试维度感知加速度（FCP/LCP）：衡量页面渲染速度；加载响应度（FID/TTI）：衡量交互准备时间；视觉稳定性（CLS）：衡量布局偏移程度。二、核心性能指标与测试实操1. FCP（首次内容绘制）定义：浏览器...

这个主要还是围绕在一些自动化测试，然后一些项目的风险管理的一些考察定位bug，然后反正就是那一堆的常规的业务场景题还是挺简单的，然后怎么写的UI自动化，怎么写的性能测试之类的，然后没啥特别难的八股问题，问了一个if else和switch的区别，这一块儿确实是太简单了。然后最后问了一下他那个是做啥的，是做一个跨境电商的建站的，涉及前端的比较多，接口层面的相对来说比较少一些，那就基本上是客户端测试，就不是服务端测试，然后测试中心有100多个人，然后涉及到一些交易呀，商品呐，大数据呀之类的相关的组。然后我问了一下会不会有一些专项？他说还是有很多专项的，你进来可能也跑不了的，然后一些AI测试啊什么的，自动化测试也有不少的相关的一些专项工作。然后我最后说如果觉得我还行的话，麻烦尽快推进吧，再不推进我就入职别的公司了。我对这家公司还是挺心仪的。

一、RAG（检索增强生成）基础与优化方向RAG是一种结合检索与语言模型生成的技术，核心流程包括：数据收集：将数据分块、生成向量嵌入并存储到数据库；推理过程：根据用户查询检索相关文档，结合提示生成回答。文章提出RAG优化的4个关键方向：分块方法、嵌入模型、向量搜索策略、提示工程，并通过实验验证效果。二、4种优化策略及实验验证分块方法优化目标：平衡块大小，避免过小（丢失上下文）或过大（检索冗余）。实验：尝试“父文档检索器”，同时检索相关片段及其父文档以保留上下文，但结果显示性能下降（如上下文召回率降低），需进一步调整分块逻辑。嵌入模型选择对比：DPR（密集 Passage 检索模型）和Senten...