先量化再动手
页面变慢时最容易犯的错是凭感觉改代码。先用浏览器性能面板录一段真实用户操作，把时间轴拆成脚本执行、样式计算、布局、绘制四段，看哪一段占比最大。
如果脚本执行占比高，方向在组件渲染与响应式依赖；如果样式计算和布局占比高，方向在 DOM 数量和 CSS 选择器；如果绘制占比高，方向在图层与阴影滤镜。
框架自带的开发者工具性能面板能直接给出组件渲染耗时排行，比人肉猜测可靠。录制时务必用生产构建，开发构建的耗时没有参考价值。
控制响应式数据的粒度
用 reactive 包一个层级很深的大对象时，任何一层属性变化都会触发依赖该对象的组件重新渲染。把大对象拆成多个 ref，或者用浅层响应式加手动触发更新，能减少无谓渲染。
列表数据只用于展示、不会被就地修改时，用浅层响应式或标记为原始对象跳过深层代理。这两个接口的语义是不再追踪内部变化，需要更新时整体替换引用即可。
计算属性里避免做重计算。如果计算函数里有排序、过滤、深拷贝，考虑缓存起来，或者在数据源变更时算一次，而不是每次依赖变化都重跑。
列表渲染的键与虚拟滚动
循环渲染的键必须用业务唯一标识，不能用数组下标。用下标时，插入或删除会让框架复用错位的节点，导致输入框内容串位这类难查的问题。
列表超过一两百条并且单项结构较复杂时，虚拟滚动是收益最直接的手段。只渲染视口内加缓冲区若干项，节点数量与列表总长度解耦。
固定行高场景实现简单，动态行高需要测量并缓存每项高度，复杂度会上升。数据量不大时不要过早引入，增加维护成本却无明显收益。
路由与资源拆分
按路由做代码分割是默认行为，但要检查页面级组件是否被静态引入进了主包。布局组件里引入了重型图表库，会把体积推给所有页面。
第三方库按需引入，图标和组件库避免全量注册。构建产物用可视化分析插件看一遍，找出体积异常的产物文件，再决定是拆分还是替换。
首屏关键资源用预加载提前拉取，非关键的路由组件保持懒加载。图片统一走懒加载与响应式尺寸，避免把大图放进首屏资源列表。
依赖排查与回归基线
监听器里如果有接口请求，要确认是否会因为依赖抖动被反复触发。对高频变化的依赖加防抖，或者控制触发时机。组件卸载时要清理定时器、事件监听、长连接，用统一的生命周期钩子收口，比分散在各处写更不容易漏。
排查内存泄漏时，反复进出同一个页面并强制垃圾回收，看性能面板里的堆大小是否回落。不回落说明有引用没被释放，重点看全局缓存和未解绑的监听。
优化前后都要留数：录制的性能火焰图、构建产物体积报告、关键交互的耗时。没有基线，改动是否有效就只能靠感觉。
把体积检查接进持续集成，超过阈值直接失败，能防止后续提交悄悄把包变大。性能问题多是逐步累积的，靠定期回归比事后救火省力。
