Vue 3 组合式API深度解析：告别混乱的组件逻辑

在Vue 2时代，我们习惯用Options API组织组件逻辑：data、computed、methods、watch各占一处。当组件逐渐庞大，你会发现一个功能的代码被拆散到不同的选项中，阅读时需要上下跳转，维护成本骤增。Vue 3推出的组合式API（Composition API）彻底改变了这一局面，它让我们能够按照功能逻辑而非选项类型来组织代码，让组件变得清晰、可复用、可测试。

为什么需要组合式API？

Options API的核心问题在于“逻辑分散”。假设一个用户列表组件，它需要处理搜索、分页、筛选三个逻辑，在Options API中，每个逻辑的数据都放在data里，方法放在methods里，计算属性放在computed里。当这三个逻辑交织在一起，阅读源码就像在拼图。更糟糕的是，复用逻辑只能靠mixins，而mixins的命名冲突和隐式依赖让人头疼。组合式API应运而生，它允许我们将同一个功能的代码写在一起，类似一个函数块，从而让组件结构更接近人的思维模式。

核心API：ref与reactive

组合式API的基石是响应式系统。在setup函数中，我们使用ref和reactive创建响应式数据。ref用于包装基本类型（也可以包装对象，但访问时需要.value），reactive用于包装对象类型。简单区分：如果你的变量是数字、字符串、布尔值，用ref；如果是一个复杂的对象或数组，用reactive。但要注意，reactive返回的代理对象在解构后会丢失响应性，所以通常搭配toRefs使用。而ref在模板中会自动解包，显得更直观。实际开发中，我更推荐统一使用ref，通过ref的一个对象属性来管理复杂数据，这样更容易保持心智模型的一致性。

计算属性与侦听器：computed与watch

在组合式API中，computed和watch都以独立函数的形式存在。computed用来声明基于响应式数据的派生状态，它缓存了计算结果，只有依赖变化时才会重新计算。例如：

js const searchText = ref('') const filteredList = computed(() => { return list.value.filter(item => item.name.includes(searchText.value)) })

watch则用于执行副作用，比如异步请求或DOM操作。它支持监听单个或多个源，还能配置deep和immediate。与watch类似的还有watchEffect，它自动追踪内部用到的响应式依赖，并在依赖变化时重新执行，适合需要同时跟踪多个依赖的场景。使用这些函数，你可以把数据流转和副作用逻辑集中在一处，而不是分散在watch选项的各个handler中。

生命周期与逻辑复用

组合式API中的生命周期钩子被重命名为onMounted、onUpdated、onUnmounted等，它们必须在setup中同步调用。这带来了一个巨大的好处：你可以在一个功能模块里同时包含数据、计算属性、监听器和生命周期钩子，形成完整的业务单元。

更重要的是，我们可以把这种业务单元提取成“组合式函数”（Composable）。例如，封装一个useUserList函数，内部管理用户列表的获取、搜索、分页和错误状态。任何组件只需要调用这个函数就可以获得完整的逻辑，既避免了mixins的弊病，又实现了高内聚的复用。组合式函数是Vue 3生态中最推崇的复用模式，它能自然而然地传递响应式数据，并且让单元测试变得易于编写。

结语

组合式API并不是要彻底否定Options API，而是提供了一个更灵活、更强大的工具。对于简单的组件，Options API依然简洁；但对于复杂业务场景，组合式API让代码的组织方式回归“关注点分离”的本质——按功能切分，而不是按类型切分。它让我们告别了组件逻辑四处散落的混乱局面，也让我们更容易与他人协作、阅读和维护代码。如果你还未深入使用组合式API，不妨在下一个项目中尝试用setup脚本（<script setup>）重构一个旧组件，你将体会到一种前所未有的清晰与自如。