Vue3代码变整洁？组合式API重构指南

Vue3的组合式API并非只是语法升级，而是倡导以业务功能为单位封装逻辑——将地址选择、支付流程等完整能力抽离为独立的useXxx()函数，让setup退居“组装车间”，专注调用与解构；告别变量、方法、副作用在setup中杂糅堆砌的面条式写法，转而通过ref/reactive的语义化分工、副作用内聚管理及逻辑单元可测试可复用的设计，真正实现代码结构与业务认知的一致性——重构的关键不在换API，而在转变组织逻辑的思维方式。

因为逻辑分散在 setup 里东一块西一块，没有按功能聚类，变量、方法、副作用混在一起，自然越写越绕——这不是 Vue3 的问题，是组织方式没跟上新 API 的设计哲学。

按业务域拆分逻辑，而不是按选项类型

传统 Options API 天然按 data、methods、watch 划分，但真实业务中，一个「订单提交」功能会同时用到响应式状态、API 调用、表单校验、错误处理和加载态控制。强行拆到不同选项里，读代码时就得来回跳转。

组合式 API 的核心价值，是让你把相关逻辑封装成独立的函数：

• 把「地址选择」相关的响应式变量、搜索逻辑、省市区联动、默认地址设置，全收进 useAddressSelector()
• 把「支付流程」的状态管理、微信/支付宝切换、签名生成、回调处理，封装为 usePaymentFlow()
• 每个函数内部自洽：声明所需 ref/reactive、调用所需 API、处理自身 watch 或 onMounted 逻辑

避免 setup 里堆砌几十行“裸逻辑”

常见反模式：setup() 里直接写 20 行表单初始化、5 个 ref、3 个 computed、2 个 watch、1 个 onMounted —— 这不是组合式，这是“换汤不换药”的面条式写法。

正确做法是让 setup 变成“组装车间”而非“生产车间”：

• 只做三件事：调用多个 useXxx() 函数、解构返回值、return 暴露给模板
• 每个 useXxx() 是纯逻辑单元，可单独测试、复用、阅读
• 例如：const { items, loading, loadMore } = useInfiniteList('/api/orders') —— 一行接入完整分页能力

合理使用 ref 和 reactive，别为了“统一”而牺牲语义

有人觉得“所有状态都用 reactive 包一层更整齐”，结果对象嵌套三层、修改要写 form.value.profile.address.city，既难读又易错。

更自然的分工是：

• ref 适合基础类型、独立状态、需要被 v-model 或 watch 的单一值（如 searchQuery、isSubmitting）
• reactive 适合结构清晰、属性间强关联的对象（如整个表单数据 form、用户资料 profile）
• 深层嵌套对象慎用 reactive，改用多个扁平 ref 或嵌套 reactive + toRefs 解构

副作用和生命周期，交给逻辑单元自己管理

不要在 setup 顶层写一堆 onMounted(() => {...}) 或 watch(...)。它们属于哪个功能，就该藏在对应 useXxx() 内部。

比如 useSearchSuggest() 可以这样写：

• 内部声明 const query = ref('') 和 const suggestions = ref([])
• 用 watch(query, ...) 做防抖请求
• 用 onUnmounted(() => clearTimer()) 清理定时器
• 外部使用者只关心 query 和 suggestions，完全不用知道背后怎么工作的

组合式 API 不是语法糖，它是帮你把“人脑理解的业务模块”，映射成“代码可维护的逻辑单元”。写得像面条，往往是因为还在用旧思维组织新工具。

到这里，我们也就讲完了《Vue3代码变整洁？组合式API重构指南》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！