面试前夜，我删掉了简历里所有“精通”
上周五晚上十一点半，地铁末班车刚过国贸站，我盯着手机里那封 HR 发来的面试邀请邮件发呆。岗位是「高级前端工程师」，JD 里赫然写着：“熟悉 Vue/React，掌握性能优化，有复杂交互开发经验”。点开自己刚更新的简历——“精通 React”、“熟练掌握动画实现”、“主导过多个大型项目”……心里突然咯噔一下。
不是因为心虚（好吧，其实有点），而是想起去年双11上线前那个凌晨：一个看似简单的商品轮播组件，在低端安卓机上卡成 PPT，用户投诉暴增，产品经理在群里连发三个“？”，运维小哥幽幽补了一句：“你们前端是不是又没测真机？”
那一刻，我突然意识到：技术选型从来不是“哪个新就用哪个”，而是“哪个能稳稳扛住线上流量”。
作为一个重度依赖 Claude 和 ChatGPT 辅助 coding 的北京码农（每天通勤一小时，路上都在刷 prompt），我早就习惯了让 AI 帮我生成 boilerplate、解释报错、甚至写单元测试。但真正决定项目成败的，往往不是工具，而是对技术本质的理解和对业务场景的敬畏。
动画？别被 Lottie 带跑偏了
去年我们团队要做一个活动页，产品扔来一张 Figma，里面全是丝滑的交互动效——按钮 hover 弹跳、卡片翻转、路径绘制动画……UI 同事还贴心地附上了 Lottie JSON 文件。
“直接上 Lottie 吧，现在不都这么干？”新人小张跃跃欲试。
我看了眼文件大小：一个 JSON 2.3MB。再看目标用户画像：三线城市，40% 用户还在用千元机。Lottie 虽然炫，但在低端设备上解析 JSON + 渲染矢量图形，CPU 直接拉满。实测 iPhone 12 Pro Max 流畅如德芙，红米 Note 8 卡得像老牛拉破车。
最后我们做了个“降级方案”：
- 高端设备（通过
navigator.hardwareConcurrency和deviceMemory判断）：加载 Lottie - 中低端设备：用 CSS keyframes +
will-change: transform实现简化版动效 - 极低端或网络差：直接静态图 + 淡入
// 粗略判断设备性能（生产环境建议结合 UA + 客户端埋点）
function isHighEndDevice() {
const cores = navigator.hardwareConcurrency || 4;
const memory = navigator.deviceMemory || 4; // GB
return cores >= 6 && memory >= 6;
}
if (isHighEndDevice()) {
import('./LottieComponent').then(renderLottie);
} else {
renderSimpleAnimation();
}
教训：面试官问“你怎么做性能优化”，如果你只答“用 Lottie”，大概率挂了。真正的优化，是知道什么时候不用 Lottie。
React vs Vue？别卷了，先看团队
今年初公司要重构内部管理系统。技术选型会上，两个阵营吵翻了天：
- React 派：“生态强！Hooks 写起来爽！TypeScript 支持好！”
- Vue 派：“上手快！文档清晰！Composition API 不比 Hooks 差！”
吵到一半，CTO 淡定喝了口枸杞茶：“你们后端用 Nest.js 吧？数据库是 MongoDB？那前端就用 React。”
全场安静。
后来我才明白：技术栈的统一性，远比个人喜好重要。我们后端大量使用 RxJS 处理流数据，React 的 useEffect + useState 组合天然契合这种响应式思维；而如果强行上 Vue，就得额外引入 Vuex 或 Pinia，反而增加认知负担。
更现实的是：简历上写“精通 Vue3”和“精通 React”，在中小厂可能没区别，但在大厂，团队技术栈就是硬门槛。我朋友面字节，简历写 Vue，结果岗位要求 React，HR 直接说“不匹配”。
所以现在我更新简历时，会根据目标公司调整关键词：
- 投阿里系？突出 React + TypeScript + 微前端
- 投腾讯系？强调 Vue3 + Vite + 小程序
- 外企？重点写 Web Components + Accessibility
别让“全栈”变成“全不会”。
面试题里的陷阱：你以为的“简单题”
最近帮同事 mock 面试，问了个经典题：“React setState 是同步还是异步？”
他脱口而出：“异步！”
我追问：“那在 setTimeout 里呢？”
他愣了三秒：“……同步？”
其实这个问题背后，考察的是对 React 执行机制的理解，而不是背答案。setState 的“异步”本质是 React 的批量更新策略（batching），在合成事件和生命周期中触发，但在原生事件、setTimeout、Promise 中，由于脱离了 React 的控制流，就会同步执行。
更坑的是，React 18 的 automatic batching 让这个规则更复杂了——现在连 setTimeout 里也会 batching！
// React 18 中，以下代码只会 re-render 一次
setTimeout(() => {
setCount(c => c + 1);
setFlag(f => !f);
}, 0);
很多候选人背了“异步”，却不知道为什么异步，更不知道 React 18 的变化。面试官要的不是标准答案，而是你的思考过程。
所以我现在准备面试题，不再死记硬背，而是：
- 用 CodeSandbox 写 demo 验证
- 看 React 源码相关部分（比如
react-dom/src/events/ReactDOMUpdateBatching.js） - 总结成自己的语言，比如：“setState 的异步是为了避免重复渲染，React 会把多次状态更新合并成一次”
简历上的“精通”，其实是“踩过坑”
说到简历，我曾经也爱写“精通 Webpack”。直到有一次线上构建失败，报错：
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
原因是某个 loader 在处理 SVG 时内存泄漏。我花了三天才定位到是 svg-sprite-loader 的旧版本 bug。从那以后，我的简历改成了：“熟悉 Webpack，有复杂项目构建及性能调优经验”。
“精通”这个词，在技术圈等于“请来挑战我”。
现在我写简历遵循一个原则：每个技术点，都要能讲出至少一个线上事故或优化案例。比如：
- 写“熟悉性能优化” → 能说出如何用 Lighthouse 从 40 分提到 90+
- 写“掌握动画” → 能对比 CSS/JS/Web Animations API 的适用场景
- 写“了解微前端” → 能聊 qiankun 的沙箱原理和样式隔离方案
HR 可能不懂技术，但面试官一定懂。简历不是自我吹嘘的地方，而是面试问题的预告片。
命令行党の倔强：为什么我坚持用 CLI
作为 Claude Code 的早期尝鲜用户，我几乎所有操作都在终端完成。不是装 X，而是效率真的高。
举个例子：昨天要排查一个线上白屏问题。我直接：
# 1. 用 curl 模拟低端机 UA 请求
curl -H "User-Agent: Mozilla/5.0 (Linux; Android 8.0)" https://our-site.com | grep -i error
# 2. 用 wrk 测接口响应
wrk -t4 -c100 -d30s https://api.our-site.com/data
# 3. 用 source-map-explorer 分析 bundle
npx source-map-explorer build/static/js/*.js --html > report.html
三分钟定位到是某个第三方 SDK 在低版本 Chrome 上报错，阻塞了主逻辑。要是用 DevTools，还得开浏览器、清缓存、模拟网络……太慢了。
命令行就像瑞士军刀，小巧但致命。而且，当你在面试中说“我用 wrk 压测过接口”，比说“我会性能测试”可信一万倍。
最后的碎碎念
技术探索的路上，我越来越觉得：工具只是杠杆，支点才是认知。
ChatGPT 能帮我写代码，但不能替我决定用 React 还是 Vue；
Lottie 能做出炫酷动画，但不能保证低端机不卡顿；
简历能包装经历，但撑不过面试官的灵魂拷问。
所以现在的我，通勤路上不再盲目刷面经，而是：
- 用 Claude 解读 RFC（比如 React Server Components）
- 在 Codesandbox 里复现经典面试题
- 给开源项目提 PR（哪怕只是文档 typo）
真正的竞争力，不是你会多少框架，而是你能否在约束条件下，做出最合适的决策。
对了，今天面试结果出来了——过了。面试官最后问：“看你简历写‘熟悉前端动画’，能聊聊 Lottie 的局限吗？”
我笑了：“当然，比如它在 2MB 的时候，就不该用。”
评论 0