Composition API 通过更细粒度依赖追踪、静态提升与编译优化、减少代理开销及可控副作用，使渲染器更高效；初次渲染快约55%，更新性能提升133%，内存减少54%。
Composition API 对渲染器优化更友好，核心在于它让 Vue 的响应式追踪和更新机制能更精准、更轻量地工作。
更细粒度的依赖追踪
Vue3 的响应式系统基于 Proxy，而 Composition API 的写法天然配合这套机制。比如用 ref() 或 reactive() 声明的状态，只会把真正被模板或计算属性读取的字段纳入依赖关系。当某个 ref 没被模板使用，它的变化就不会触发组件重渲染；而 Options API 中，data 里声明的所有字段默认都可能被追踪，哪怕实际没用到。这减少了不必要的更新开销。
静态提升与编译时优化更充分
Composition API（尤其是 <script setup>）写出的代码结构更扁平、逻辑更内聚，Vue 编译器更容易识别哪些变量是响应式的、哪些是常量、哪些只在初始化时用。例如：
-
const count = ref(0)被明确标记为响应式 -
const title = '首页'是普通常量，编译时可直接提升为静态节点 -
computed(() => ...)的依赖关系清晰可析，编译器能提前锁定其响应链
这种确定性让编译器可以做更多 Tree-shaking 和静态分析，生成更小、更快的渲染函数。
减少运行时代理开销
Options API 需要把整个 data 对象包装成响应式，并在每次访问时通过 this.xxx 触发 getter。而 Composition API 中，ref 和 reactive 是按需创建的独立响应单元，没有统一的 this 上下文代理层。组件实例不再需要维护庞大的响应式代理对象，内存占用更低，初始化更快。
生命周期与副作用更可控onMounted、watch 等钩子在 setup 内按需导入和调用，它们的执行时机和依赖范围明确。渲染器能更准确判断哪些副作用需要同步执行、哪些可以延迟或跳过——尤其在 SSR 或 suspense 场景下，这种可控性直接转化为首屏渲染速度的提升。
- 初次渲染快约 55%
- 更新性能提升约 133%
- 内存使用减少约 54%
这些数据背后，是 Composition API 让框架“知道得更清楚”：什么变了、谁用了、要不要重绘。不是单纯语法糖，而是从设计上为渲染器减负。
