Vue3 Composable 该按什么边界抽

Vue3 推出组合式 API 以后，团队很容易迅速进入“什么都抽成 composable”的阶段。它确实解决了 Options API 里逻辑分散的问题，但抽法不对，同样会让页面越来越难懂。

我在 2021 年更认可的一条经验是: composable 最好围绕“业务能力”而不是围绕“语法类别”来组织。

优先按功能闭环来拆

比如一个列表页面里，分页、筛选、刷新、重置这些动作明显属于同一组能力，把它们放进一个 composable 很自然。

但如果只是把 ref、watch、computed 分别抽走，表面上像是在复用，实际只是在把语法碎片搬家。

一个 composable 最好回答一个问题

我通常会问自己: 这个 composable 暴露出来，到底是为了让页面“多了什么能力”？

如果答案很清晰，比如“管理文章列表查询”“管理弹窗开关”“管理权限按钮显隐”，说明边界大概率是对的。反过来，如果它什么都管一点，就已经在变胖了。

不要让 composable 偷偷依赖页面私有状态

组合式 API 很容易把一个 composable 写成“只能在当前页面里用”的半成品，比如它默认依赖某个路由参数、某个全局 store 字段、某个特定组件事件。

这种写法短期也能跑，但复用价值很弱。更稳的方式是把依赖做成显式参数，让页面决定传什么进去。

返回值要控制在可理解范围内

有些 composable 一返回就是十几个状态、七八个方法，使用方必须滚很久才能知道自己应该拿哪个。这样的抽象往往说明边界还没理顺。

宁可拆成两个小一点但语义清楚的 composable，也不要为了“少建文件”把所有状态塞一起。

小结

Vue3 composable 的核心价值，是让一组相关逻辑重新聚合起来。只要围绕能力边界去拆，而不是围绕语法习惯去拆，复杂页面的可维护性会明显提升。