拼多多前端一面凉经

《面试题目》

1. 请做个自我介绍。
2. 说一个你认为最能体现你前端能力的亮点。
3. 项目拷打：介绍一下你做的项目。
4. 手撕代码：写一个计算页面 FPS 的函数（与候选人自己的项目相关）。

《参考解析》

「最能体现前端能力的亮点」要挑一件有技术纵深、能被追问三层的事说，而不是罗列技术栈。 稳妥的结构是「场景 → 难点 → 我的方案 → 量化结果 → 反思」。例如首屏性能优化：先说清原来 LCP 多少、卡在哪一段（资源体积、请求瀑布、渲染阻塞），再讲你具体做了哪几件事（路由级代码分割、关键 CSS 内联、图片懒加载与格式替换、接口并行化），最后给优化前后的数字对比和监控方式。尽量避免说「我用了 React/Vue 写了很多页面」——这是工作量不是亮点；也避免说「我封装了很多组件」，除非能讲清组件的抽象边界、复用收益和被多少个业务方使用。

计算页面 FPS 的标准写法是 requestAnimationFrame 计数法。 思路是：requestAnimationFrame 的回调在每一帧渲染前触发，因此统计一秒内回调触发的次数就近似得到帧率。实现上用一个计数器累加，每满一秒（或用 performance.now() 判断时间差 ≥ 1000ms）把计数除以实际耗时乘以 1000 得到 fps，输出后清零重新计数；用 performance.now() 而不是 Date.now() 是因为前者单调递增且精度更高，不受系统时间调整影响。要主动补充的几个点：① 这个值反映的是 rAF 的回调频率，页面被隐藏（切到后台标签页）时浏览器会把 rAF 降到几乎不触发，所以要监听 visibilitychange 暂停统计，否则会看到假的 0 fps；② 单帧耗时更能定位卡顿，可以配合 PerformanceObserver 监听 longtask（超过 50ms 的任务）或 event 的 durationThreshold；③ 更精细的帧耗时可以用 requestAnimationFrame 回调参数里的时间戳做差分，统计帧间隔的 P95/P99 而不只是平均值，因为平均值会把偶发卡顿抹平；④ 生产环境上报要采样，别每帧都发请求。答完可以延伸一句「Chrome 里也可以用 PerformanceObserver 的 paint/largest-contentful-paint 条目配合，或用 chrome://tracing 核对」，显示你知道工具链的位置。

面试复盘这一环值得当成固定动作。 这位作者提到面试官主动复盘并指出了问题，这种场合要当场把追问记下来，回去补成可复述的答案；如果面试官问「你觉得自己哪里答得不好」，诚实指出一处并说明事后怎么补的，比硬说「都还行」更容易留下好印象。前端一面的项目深挖通常顺着简历往下问三层：这个功能为什么这么设计 → 换一种方案会怎样 → 线上出过什么问题、怎么定位的，准备时按这三层各写一遍自己的说法。