性能面试反问与陷阱题

陷阱 1：你说优化了 30%，怎么证明不是偶然

我一般不会只报一个百分比，而会先讲基线和口径。比如优化前看的是 p75 的 LCP 还是平均值，优化后看的是同一页面、同一设备分布还是全站均值。这样先把口径说清楚，面试官会更相信你是真的做过，而不是随口报了个数字。

这个时候我不会硬编。我会直接说，性能优化不一定每次都能拿到完整业务指标，但至少会确认三层结果：指标有没有改善、用户体感有没有改善、线上反馈和问题工单有没有减少。没有业务转化数据，不代表没有工程价值，关键是别编数据。

我会说这通常是错误方向。因为真正的问题很多时候不是组件本身慢，而是状态边界太大，导致整棵树一起刷新。到处加 memo 会增加复杂度，但未必有收益。我的顺序一般是先缩小更新影响范围，再考虑局部缓存。

我不会先怀疑用户，而会先确认是不是口径和场景不匹配。比如监控看的可能是全站 p75，但用户遇到的是某个特殊设备、高数据量或者特定操作链路的问题。也就是说，指标和体感不一致时，我会优先怀疑采样口径、场景切片和上下文信息，而不是简单说“指标没问题”。

我一般会先看 TTFB、接口耗时和主线程长任务。如果首包和接口明显慢，那更偏后端或网络；如果接口正常但交互迟迟没有反馈、React 重渲染很多，那更偏前端。很多时候两边都有关，但面试里要表现出你知道先从哪一层切。

我会说复现不了不代表没法查。这个时候我会更依赖监控平台、日志、录屏、设备信息、网络环境和操作链路，把上下文先收齐，再判断是特定场景还是普遍问题。面试官其实想看的是你会不会先收集信息，而不是一上来猜代码。

我会优先做用户体感最明显、收益最直接、验证最快的动作。比如首屏慢先动首屏资源和关键渲染路径，列表卡先上虚拟列表，输入卡先拆长任务。也就是说，我不会追求一次把架构改到最完美，而会先做最值的一步。

性能面试里的陷阱，很多不是考你会不会术语，而是看你会不会乱报数据、乱用优化手段、乱下结论。我的思路一直是先讲口径，再讲定位，再讲取舍。