组合式 api 的核心是按业务域封装逻辑单元，而非按选项类型拆分；应将相关状态、方法、副作用收进独立的 usexxx() 函数，让 setup 仅负责组装调用与解构返回值。
因为逻辑分散在 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 不是语法糖，它是帮你把“人脑理解的业务模块”，映射成“代码可维护的逻辑单元”。写得像面条，往往是因为还在用旧思维组织新工具。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
