Vue.js编译器本身不直接触发渲染瓶颈，真正影响性能的是运行时的响应式更新、虚拟DOM diff和DOM操作；模板结构决定diff范围上限，响应式粒度决定更新触发密度，静态内容识别存在边界，构建优化无法弥补运行时设计缺陷。
Vue.js 编译器本身不直接触发渲染瓶颈——它只在构建阶段把模板编译成渲染函数，真正影响性能的是运行时的响应式更新、虚拟 DOM diff 和 DOM 操作。所谓“编译器优化的极限”，本质是模板结构和数据组织方式对后续运行时效率的约束边界。
模板结构决定 diff 范围上限
Vue 的 diff 算法在最坏情况下时间复杂度可达 O(n³)，当模板嵌套过深、列表无 key、或频繁打乱顺序时，diff 成本会指数级上升。
- 避免
v-for内部包含大量动态子组件或深层插槽：每多一层嵌套，diff 深度+1，节点比对量翻倍 - 禁止用
:key="index"：数组顺序变动（如 unshift、splice）会导致全量节点重建，而非复用 - 不用
v-if+v-for同级：编译后生成冗余条件分支逻辑，增加渲染函数体积和执行路径
响应式粒度决定更新触发密度
编译器无法感知数据是否真的需要响应式——它默认把所有 data、props、setup() 中的 ref/reactive 全部代理。一旦对象过大或嵌套过深，getter/setter 的拦截开销就成为瓶颈。
- 超 5000 个响应式属性时，Proxy 初始化内存占用可能超 30MB，首次挂载延迟明显
- 大型列表（如 1000+ 条）不要用
ref([])直接包裹，改用shallowRef或Object.freeze - 配置类对象（如表单 schema）用
shallowReactive，避免递归代理内部字段
静态内容识别能力存在实际边界
v-once 和 v-memo 是编译器可识别的静态标记，但它们生效的前提是：表达式必须在编译期可判定为常量或稳定依赖。
立即学习“前端免费学习笔记（深入）”；
-
v-memo="[a, b]"中若a或b是 computed 或深层响应式对象，实际仍会频繁重计算依赖，失去 memo 效果 - 带函数调用的表达式（如
{{ formatTime(date) }}）无法被静态分析，永远走运行时求值 - 插槽内容、作用域插槽、
v-html内容均绕过编译优化，完全交由运行时处理
构建时优化无法弥补运行时设计缺陷
Tree Shaking、模板预编译、懒加载等构建层手段，能减小包体积、加速 JS 解析，但无法降低单次 render 的计算压力。当一个组件模板含 2000 个节点且每帧都更新，再小的代码包也救不了卡顿。
- 首屏渲染超过 2000 个真实 DOM 节点时，Chrome Performance 实测平均耗时 >300ms
- 滚动场景下，未启用虚拟滚动的万级列表，GPU 内存飙升、掉帧率超 40%
- 高频输入（如搜索框）若绑定
@input直接触发复杂 computed，CPU 占用持续 90%+
