面灵AI→

携程前端秋招二面:性能指标排查与实习项目复盘

轮次
二面
时间
2026-10
来源
牛客网

《面试题目》

  1. 自我介绍。
  2. 讲一下你的实习详情。
  3. 作为实习生独立 owner 项目时遇到的难点是什么?技术选型是怎么做的?
  4. 从收到 PRD 开始,完成业务开发的流程是怎样的?
  5. 产品、运营在验收的时候有什么反馈?
  6. 如果重新做这个项目,会有哪些改进?
  7. 详细讲讲性能优化是怎么做的?
  8. 刚才讲到了性能相关的指标,你了解 Web 的性能指标有哪些吗?
  9. 如果性能指标异常,你该如何排查?
  10. 具体到长任务,你的实际举措是什么?
  11. 结合 AI 的技改:在实习过程中使用公司其他人开发的 AI 工具,有什么想法和建议?
  12. 知识问答平台这个项目,你参与了哪一部分工作?
  13. 如何评估这套知识库索引机制的效果?
  14. 反问。

《参考解析》

独立 owner 的项目,面试官想听的是决策过程,不是需求描述。 讲这类项目按「背景与目标 → 可选方案 → 为什么选这个 → 落地过程 → 结果」走,把技术选型的约束条件说具体:团队技术栈与既有基建、交付周期、后续维护人是谁、性能与成本的量化要求。同时准备两三个「当时权衡后放弃的方案」,以及放弃的理由(比如选了轮询而不是长连接,因为服务端改造排期不够、且实时性要求只有分钟级)。这样被追问「为什么不用 X」时不至于临场编。成果尽量给数字:首屏耗时、请求数、错误率、返工次数,拿不到精确值就说明口径和大致量级,别含糊。

从 PRD 到上线的流程要讲成一条有卡点的链路。 典型环节是:需求评审澄清边界与验收标准 → 技术方案设计(接口契约、数据结构、异常与埋点)→ 排期拆分与联调对齐 → 开发自测(单测、兼容性、边界态)→ 提测与验收(产品看功能、运营看配置与文案)→ 灰度与上线 → 观测与回滚预案。加分点在于说清「你会主动在哪些环节补位」:评审时把模糊需求问成可验收的标准、方案阶段就把埋点和降级点定好、上线前准备回滚开关。产品与运营验收的反馈通常集中在体验细节(加载态、空态、错误提示、文案与配置项),能举一两个真实反馈并说明怎么改的,比说「没什么反馈」可信。

Web 性能指标按「加载、交互、视觉稳定」三类答。 加载类是 FP、FCP、LCP 与 TTFB,衡量「内容什么时候可见」;交互类是 FID 与其替代指标 INP,以及 TBT,衡量「点了之后多久有反应」;视觉稳定类是 CLS,衡量布局抖动。再补上实验室指标与真实用户指标的区别:Lighthouse 是受控环境、可复现但不代表真实分布,CrUX 或自建 RUM 是真实用户分布、适合看 P75 与分渠道差异。面试官接着问「具体到长任务」,要落到 Long Task 与主线程阻塞:长任务指占用主线程超过 50ms 的任务,它推迟了输入响应与渲染。实际举措是拆分与让路——把大计算搬到 Web Worker、用时间切片(requestIdleCallback、scheduler.yield)把长循环切成小块、大列表用虚拟滚动减少 DOM、避免同步布局抖动(读写样式分离)、把非关键脚本标记 async/defer 并在空闲时再初始化。

指标异常的排查顺序是先定位是哪一段慢,再定位是谁慢。 第一步看分布而不是看均值:按设备、网络、地区、版本、页面维度切片 RUM 数据,确认是全量劣化还是某一类用户劣化——常见误判就是拿实验室数据解释真实用户问题。第二步按时间轴对齐:从 TTFB 到 FCP 到 LCP 逐段判断瓶颈在网络、服务端还是前端渲染;TTFB 高说明服务端或 CDN 慢,FCP 前卡住多为阻塞渲染的资源,LCP 晚通常是首屏大图、字体或首屏数据请求。第三步看主线程:用 Performance 面板或火焰图找长任务、看是否有频繁的强制同步布局、内存是否持续增长。第四步做对照验证:把可疑改动回滚或加开关对比,用小流量实验确认因果,再给出优化与防回归手段(把指标接进监控、设置预算与告警)。

知识库索引机制的效果要区分「检索层」和「端到端」。 检索层看召回率与排序质量:准备一批带标准答案的问题集,人工标注每个问题的相关文档,评估 Hit Rate、MRR、NDCG,并单独看「召回为空」的比例;同时观察切分粒度的影响——块太大语义被稀释、太小上下文不完整。端到端看答案质量:回答是否命中要点、引用是否可回溯、资料不足时是否老实说不知道,再结合用户侧信号(追问率、点踩率、复制率、停留时长)做辅助判断。评估要先有基线再谈优化,任何一次索引或切分策略调整都在同一套测试集上对比,同时监控线上分布是否漂移。

对内部 AI 工具的建议按「提效点 + 阻塞点」组织。 有效的说法是:它在什么环节确实省了时间(生成样板代码、写测试用例、解释陌生模块)、在什么环节不可靠(对内部框架与业务约定的理解、生成的代码缺少项目规范与埋点),并给一条能落地的改进建议,比如接入仓库上下文与代码规范、把生成结果做成可评审的草稿而不是直接提交、给常用工具统一入口与权限。全程不提具体公司内部信息,只讲方法层面的观察与取舍。