性能调优需满足用户可感知卡顿、核心指标超标、高风险场景或技术债积累等明确条件，而非盲目进行；应以守住用户体验底线为原则，卡了再优化。
性能调优不是开发流程的固定环节，而是有明确触发条件的针对性动作。盲目优化浪费时间，该优化时不优化则影响体验。核心判断标准就一条：用户可感知的卡顿或延迟已经出现——比如列表滚动掉帧、表单输入卡顿、首屏加载超过2秒、点击按钮响应迟滞。
从指标看是否该优化
用真实数据代替主观感受：
- 首屏时间（FCP）＞1.5秒：说明加载或渲染存在瓶颈，需查 Network 面板和 Lighthouse 报告
- FPS 持续低于 50：在 Chrome DevTools 的 Performance 面板录制操作，Bottom-up 视图中看到大量“Scripting”或“Rendering”耗时高
- 内存占用持续增长：反复进入退出同一页面后内存不回落，可能有响应式泄漏或未销毁监听
- 组件重渲染次数异常：用 Vue DevTools 查看组件的“Reactivity”标签，发现无关数据变更也触发了渲染
从场景看是否该优化
以下情况属于“必须提前考虑”，不是等出问题再补救：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 列表项超过 200 条且支持滚动或搜索
- 表单字段多于 10 个，且含实时校验或联动计算
- 页面包含第三方 UI 组件库（如 Element Plus、Ant Design Vue）的复杂表格或树形控件
- 使用了深层嵌套对象或大型配置对象（如 10KB+ 的 JSON Schema）作为响应式数据
从技术债看是否该优化
这些写法本身不报错，但埋下性能隐患，建议重构：
立即学习“前端免费学习笔记（深入）”；
- v-for 中 key 用 index 或 Math.random()
- 模板里直接写三元运算、函数调用或链式取值（如 {{ user.profile?.address?.city }}）
- 一个 composable 里混合管理高频变化（如输入框）和低频变化（如权限配置）
- 把静态配置（如 API 地址、主题色）放进 reactive 或 ref 而非普通 const 对象
优化不是为了追求理论极致，而是守住用户体验底线。卡了再动，不卡不碰，比“一上来就加 computed、shallowRef、v-memo”更务实。
