Vue3 composable 的边界感比复用更重要

Vue3 推出 composable 之后，很多原本散落在组件里的逻辑终于有了更自然的抽离方式。但用得久了我越来越觉得，composable 最大的风险不是不好复用，而是“什么都想塞进去”，最后边界比 mixin 时代还模糊。

一个健康的 composable，应该回答得很清楚：它到底提供的是状态、动作，还是纯计算结果。只要一个 composable 同时开始接管请求、表单展示、弹窗控制和业务判断，它就不再是一个干净的抽象，而是在悄悄吞掉组件层职责。

我比较习惯的做法是让 composable 尽量只承载一类能力。比如列表查询状态归一类，表单提交动作归一类，权限判断归一类。这样一来，组件仍然保留页面编排能力，而不是完全变成“调用若干黑盒后拼模板”的壳子。

复用当然重要，但比复用更重要的是能不能看懂。一个边界清晰的 composable，即便暂时只有两个页面使用，也比一个“什么都管一点”的万能函数更有长期价值。

Vue3 给了我们更好的逻辑组织工具，但工具越顺手，越要主动控制边界。只有这样，项目增长后才不会重新掉回难拆难改的状态里。

前端里的很多“体验问题”本质上都是边界问题

围绕「Vue3 composable 的边界感比复用更重要」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。