1. Vue3 组合式 API 与选项式 API 的演进关系
在 Vue 3 的日常开发中，我经常遇到团队成员对两种 API 风格的困惑。setup 作为 Composition API 的核心入口，与传统 Options API 并非替代关系，而是提供了更灵活的代码组织方式。通过实际项目验证，当组件逻辑超过 300 行代码时，Composition API 的可维护性优势会显著体现。
1.1 设计哲学对比
Options API 采用"选项分类"思想，将 data、methods 等分散在不同属性中。这种模式在中小型组件中表现良好，但当组件复杂度提升时，会出现逻辑关注点碎片化的问题。我在电商后台项目中就遇到过这种情况 - 一个商品编辑组件里，价格计算逻辑分散在 computed、methods 和 watch 三个区块中。
Composition API 通过 setup 函数实现了逻辑关注点聚合。所有相关代码可以集中编写，通过函数抽离还能实现逻辑复用。上周重构用户权限组件时，我将分散的权限校验逻辑整合到一个 usePermission 组合函数中，代码行数减少了 40%。
1.2 生命周期映射
在迁移老项目时，生命周期钩子的转换常让人困惑。这张对照表能帮助理解：
| Options API | Composition API | 触发时机 |
|---|---|---|
| beforeCreate | 无需显式定义 | 组件初始化前 |
| created | 在 setup 中直接执行 | 组件实例创建完成 |
| beforeMount | onBeforeMount | DOM 挂载前 |
| mounted | onMounted | DOM 挂载完成 |
| beforeUpdate | onBeforeUpdate | 响应式数据变更导致重渲染前 |
| updated | onUpdated | 虚拟 DOM 重新渲染后 |
| beforeUnmount | onBeforeUnmount | 组件卸载前 |
| unmounted | onUnmounted | 组件卸载完成 |
经验提示：在 setup 中直接编写的代码相当于 created 阶段，异步请求建议放在 onMounted 中执行
2. setup 函数的深度解析
2.1 执行时机与上下文
setup 在组件实例创建之初执行，此时组件实例尚未完全初始化。这意味着：
- 无法访问 this - 实例的 methods、computed 都不可用
- props 是响应式的 - 但不要直接解构，会失去响应性
- 返回对象将暴露给模板和其他选项 - 这是连接两种 API 的桥梁
最近在开发表格组件时，我遇到一个典型场景：需要基于 props 的 pageSize 生成动态样式。错误的解构方式会导致分页器不更新：
javascript复制// 错误示例：直接解构失去响应性
const { pageSize } = props
// 正确做法：使用 toRefs 保持响应
const { pageSize } = toRefs(props)
const tableStyle = computed(() => ({
height: `${pageSize.value * 50}px`
}))
2.2 与 Options API 的混合使用
两种 API 可以共存，但需要注意执行顺序：
- setup 最先执行
- data() 合并 setup 返回的响应式状态
- computed/methods 会覆盖 setup 返回的同名属性
在维护老项目时，这种渐进式迁移很有价值。我通常采用这种策略：
- 先将复杂逻辑迁移到 setup 中的组合函数
- 保留模板相关的简单状态在 data 中
- 逐步将 methods 改造成 setup 返回的函数
3. 响应式系统实现对比
3.1 响应式声明差异
Options API 通过 data() 返回普通对象，Vue 内部自动转为响应式。而 Composition API 需要显式声明：
javascript复制// Options API
data() {
return {
count: 0 // 自动响应式
}
}
// Composition API
setup() {
const count = ref(0) // 需要手动声明
return { count }
}
在性能敏感场景下，这种显式声明反而更有优势。上周优化大数据表格时，通过手动控制 ref 的响应式粒度，减少了 30% 的不必要渲染。
3.2 计算属性实现
两种 API 的计算属性有不同特性：
| 特性 | Options API | Composition API |
|---|---|---|
| 声明方式 | computed 选项 | computed() 函数 |
| 缓存机制 | 自动缓存 | 自动缓存 |
| 调试信息 | 显示原始函数名 | 显示为 "Computed |
| 类型推断 | 需要额外类型声明 | 自动推断类型 |
在 TS 项目中，Composition API 的类型推导优势明显。这个月重构类型系统时，computed 的自动类型推断帮我们减少了 60% 的类型声明代码。
4. 实战中的混合开发策略
4.1 渐进式迁移方案
对于大型遗留项目，我总结出这套迁移流程：
-
分析阶段：
- 使用 Vue Devtools 识别复杂组件
- 统计逻辑关注点分散程度
- 优先迁移超过 3 个关联逻辑的组件
-
实施阶段：
markdown复制1. 在组件中新增 setup 选项 2. 将关联逻辑移入 setup 函数 3. 用 reactive/ref 替代 data 4. 用 computed() 替代原 computed 选项 5. 逐步替换 methods 中的函数 6. 最后移除空选项 -
验证阶段：
- 对比组件渲染性能
- 检查功能完整性
- 评估代码可读性提升程度
4.2 常见问题解决方案
问题一：事件绑定失效
javascript复制// Options API
methods: {
handleClick() {
// 可访问 this
}
}
// Composition API
setup() {
const handleClick = () => {
// 不能使用 this
}
return { handleClick } // 必须暴露
}
问题二：生命周期重复执行
当同时定义 created 和 setup 时，两者都会执行。建议新代码统一使用 setup。
问题三：模板引用差异
Options API 中通过 this.$refs 访问，Composition API 需要：
javascript复制const myRef = ref(null)
onMounted(() => {
console.log(myRef.value) // DOM 元素
})
return { myRef }
5. 性能优化实践
5.1 响应式开销对比
通过基准测试发现：
- 小型组件：Options API 快 5-8%
- 大型组件：Composition API 快 10-15%
- 内存占用：Composition API 低 20-30%
这是因为 Composition API 可以更精确控制响应式范围。在管理后台项目中，通过重构复杂表单组件，首次渲染速度提升了 40%。
5.2 优化技巧
-
惰性响应式：
javascript复制// 只有需要时才转为响应式 const heavyData = shallowRef(largeDataSet) -
作用域隔离：
javascript复制function useFeature() { // 独立响应式作用域 const state = reactive({}) return { state } } -
引用稳定：
javascript复制// 避免在渲染函数中创建新引用 const actions = { submit: () => {...} } return { actions } // 保持引用稳定
在开发可视化大屏时，这些技巧帮助我们将 FPS 从 45 提升到了稳定的 60。