第1章 岗位能力画像与简历优化模板

问答卡片 1

面试问题：请用一个具体的Vue性能优化案例，说明你如何发现问题、分析原因并解决，请提供量化的前后对比数据。

🎯 考察点：是否具备完整优化思维链（定位→分析→实施→验证）；能否用STAR结构清晰表达；量化意识。

📐 回答框架：

1. Situation：描述业务场景（如数据大屏每秒刷新，页面卡顿）
2. Task：明确优化目标（FPS从30提升到60）
3. Action：具体操作（使用Chrome Performance定位长Task，拆分更新逻辑，引入虚拟列表）
4. Result：量化结果（首屏加载减少2s、滚动帧率稳定60fps、CPU占用降低50%）

📝 示例回答（95字）：

在实时监控大屏项目中，每秒渲染2000个数据点导致页面掉帧。我通过Performance面板发现VNode更新耗时过长，改为requestAnimationFrame分片更新，并引入虚拟DOM diff跳过未变化节点。优化后FPS从25提升至58，CPU占用下降40%。

🔍 可能追问：

• 如果数据量再大10倍，你的方案还适用吗？
• 如何保证分片更新期间用户操作的交互不被阻塞？
• 你提到的“虚拟列表”，具体用哪个库？限制是什么？

问答卡片 2

面试问题：在简历中你写“使用computed与watch优化依赖更新”，请具体解释你如何判断使用哪个，并举例说明。

🎯 考察点：对Vue响应式原理的理解；能否区分计算属性与侦听器的适用场景；是否知道滥用watch导致性能问题。

📐 回答框架：

• 明确computed是纯函数，基于依赖缓存，适用于派生数据；
• watch用于执行副作用，如异步请求或DOM操作；
• 对比案例：对列表数据做过滤→用computed；监听路由变化发起请求→用watch；
• 性能陷阱：避免在computed中修改data，避免watch深度监听大量数据。

📝 示例回答（72字）：

在搜索页中，用户输入关键词需要过滤列表。我用computed: filteredList缓存过滤结果，输入变化时只重新计算相关项。同时用watch防抖处理搜索请求，而非在computed里调用API，避免了不必要的重复请求。

🔍 可能追问：

• computed和methods在模板中使用的区别，性能差多少？
• watch的immediate和deep参数有什么风险？
• 如果filteredList依赖多个data，Vue如何确保缓存失效？

问答卡片 3

面试问题：在你优化Vue项目首屏加载时，使用了哪些工具和方法？具体操作流程是怎样的？

🎯 考察点：实际工程经验；是否熟悉性能分析工具链；是否懂首屏优化全流程（网络、打包、渲染）。

📐 回答框架：

1. 工具选择：Lighthouse（整体评分）、Chrome Performance（网络/渲染）、Webpack Bundle Analyzer（包体积）。
2. 分析步骤：先看Lighthouse报告→再深入Performance的FCP、TTI→最后分析打包产物找出大模块。
3. 优化动作：路由懒加载、图片懒加载、第三方库CDN、Gzip、关键CSS内联。
4. 效果验证：通过Lighthouse二次对比，记录FCP从4.2s降到1.8s，包体积从2.1MB降到600KB。

📝 示例回答（88字）：

使用Lighthouse诊断发现FCP高达4.5s，通过Webpack Bundle Analyzer定位到lodash全量引入。改用lodash-es并按需加载，同时配置路由懒加载和keep-alive缓存常驻页面。最终FCP降至1.9s，Lighthouse评分从54提升至92。

🔍 可能追问：

• 你用的路由懒加载是怎么实现的？是否有预加载策略？
• 如何衡量优化前后真实用户的首屏体验？
• 如果项目用了SSR，你还会坚持哪种优化方法？