携程前端秋招二面:性能指标排查与实习项目复盘
- 轮次
- 二面
- 时间
- 2026-10
- 来源
- 牛客网
《面试题目》
- 自我介绍。
- 讲一下你的实习详情。
- 作为实习生独立 owner 项目时遇到的难点是什么?技术选型是怎么做的?
- 从收到 PRD 开始,完成业务开发的流程是怎样的?
- 产品、运营在验收的时候有什么反馈?
- 如果重新做这个项目,会有哪些改进?
- 详细讲讲性能优化是怎么做的?
- 刚才讲到了性能相关的指标,你了解 Web 的性能指标有哪些吗?
- 如果性能指标异常,你该如何排查?
- 具体到长任务,你的实际举措是什么?
- 结合 AI 的技改:在实习过程中使用公司其他人开发的 AI 工具,有什么想法和建议?
- 知识问答平台这个项目,你参与了哪一部分工作?
- 如何评估这套知识库索引机制的效果?
- 反问。
《参考解析》
独立 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 工具的建议按「提效点 + 阻塞点」组织。 有效的说法是:它在什么环节确实省了时间(生成样板代码、写测试用例、解释陌生模块)、在什么环节不可靠(对内部框架与业务约定的理解、生成的代码缺少项目规范与埋点),并给一条能落地的改进建议,比如接入仓库上下文与代码规范、把生成结果做成可评审的草稿而不是直接提交、给常用工具统一入口与权限。全程不提具体公司内部信息,只讲方法层面的观察与取舍。