去年一个前端工程师在GitHub吐槽：刷了300道LeetCode，面大厂时却被问懵了——"说说你设计的UI系统有哪些架构权衡"。他以为考的是框架熟练度，对方要的却是系统思维。这种错位正在批量制造面试悲剧。
从"会用React"到"懂React"，中间隔着一座山
第一道题就暴露了分水岭：React的协调（Reconciliation）机制如何工作，什么场景会触发重渲染？
初级回答往往停留在"props变了就渲染"。Senior工程师会拆解成三层：虚拟DOM比对算法、Fiber架构的优先级调度、以及被忽略的 bailout 机制——为什么同样的状态变更，有时跳过整棵子树，有时却全量计算。这背后是React团队用五年时间把O(n³)的diff降到O(n)的工程取舍。
更隐蔽的考点在第8题：内存泄漏排查。大多数人能说出useEffect的cleanup，但生产环境的泄漏往往藏在闭包陷阱、事件订阅未解绑、或者第三方库的全局缓存里。Senior的简历里通常写着一行："为XX平台定位并修复了导致页面崩溃的内存泄漏，首屏停留时长提升23%"。
Bundle优化不是砍库，是算经济账
第3题问大包体优化，常见误区是罗列Tree Shaking、Code Splitting、Gzip三板斧。真正的大厂追问的是：你量化过每个策略的收益吗？
一个真实案例：某电商App把lodash全量引入，打包分析显示它占了首屏JS的18%。但直接替换为按需加载后，转化率反而掉了——因为拆分出的几十个chunk在弱网环境下瀑布请求，TTI（可交互时间）恶化。最后的解法是用babel-plugin-lodash做编译时裁剪，配合预加载关键路径，才拿到体积和性能的平衡。
这类问题的本质是资源博弈。优化不是技术正确，是业务正确。
最狠的题根本不考技术
第6题让候选人描述与设计师、产品经理的协作方式。表面是软技能，实际在测工程影响力：你能不能把自己的技术判断翻译成业务语言？
一个典型场景：设计师坚持要用复杂的交互动画，你如何用性能数据说服对方？Senior的做法不是甩Lighthouse报告，而是建一个A/B测试框架，把"动画帧率"翻译成"跳出率变化"，让决策变成数据问题而非立场问题。
第4题更直接——"讲一个你最近交付的功能，以及它产生的影响"。没有数据支撑的回答，在这里直接出局。
accessibility 是门槛，不是加分项
第5题关于跨区域、跨能力的无障碍设计，在北美大厂已经是硬性要求。但国内很多团队把它当"政治正确"应付。真正做过国际化的人会知道：RTL（从右至左）布局不是简单翻转CSS，阿拉伯语的连字规则会让你的组件库底层架构推倒重来；而屏幕阅读器的兼容，需要从DOM语义化一路测到焦点管理。
这25道题的编排本身就在传递信号：前端工程师的晋升路径，已经从"实现需求"转向"定义问题"。框架会过时，但系统思维、性能嗅觉、跨团队协作的方法论，是穿越周期的硬通货。
最后留一道题——第7题问多团队共用代码库的状态管理。你的方案是Redux、Zustand、还是Context？或者，你有没有想过这个问题本身就是伪命题：当五个团队往同一个store里写逻辑时，真正的解法可能不是选什么工具，而是重新划分服务边界？
热门跟贴