文章目录
目录导航
快速定位文章内容
正文
Vue3 项目里，什么时候我会优先写 composable，什么时候不会
Vue3 推出 Composition API 之后，
composable 很快就成了很多项目里的默认解法。它确实能把逻辑组织得更清楚，但我现在越来越少把“代码一重复”就等同于“立刻抽 composable”。很多时候，抽得太早，反而会把本来很好懂的业务逻辑拆得更散。我会先问三个问题
在决定要不要抽 composable 之前，我通常会先问自己三件事：
- 这段逻辑是不是会被多个地方复用。
- 这段逻辑有没有稳定的输入和输出。
- 抽出来之后，调用方会不会更容易读，而不是更绕。
如果这三个问题里有两个以上答不上来，我一般不会急着抽。
适合抽成 composable 的场景
有些逻辑天然就很适合抽出来，因为边界清楚，而且和页面结构没有强耦合。
- 列表请求与分页
- 搜索条件同步
- 元素可见性监听
- 倒计时和轮询
- 权限判断和按钮显隐
这类逻辑通常都有明确的状态、动作和生命周期，用 composable 收起来以后，页面会干净很多。
export function usePagination() { const page = ref(1) const pageSize = ref(10) const setPage = (value: number) => { page.value = value } return { page, pageSize, setPage } }
不适合硬抽的场景
如果一段逻辑和当前页面的业务语义绑得很紧，我反而更倾向先留在组件里。
例如：
- 只在当前弹窗里生效的表单联动
- 只服务一个页面的临时交互
- 依赖大量模板上下文的判断
- 还在频繁变化中的需求逻辑
这类代码最大的问题，不是重复，而是不稳定。你今天刚抽出来，明天就因为另一个页面规则不同，又开始到处加参数、塞选项，最后 composable 本身反而更难维护。
我不想看到的 composable 长什么样
如果一个 composable 出现这些信号，我会重新评估：
- 参数越来越多
- 返回值越来越杂
- 里面夹着很多页面专属文案
- 调用方还得知道一堆内部细节才能正确使用
这种时候，它已经不是“复用逻辑”，而是在制造新的抽象负担。
一个更稳妥的顺序
我现在更习惯这样做：
- 先把逻辑在一个组件里跑顺。
- 等第二个、第三个相似场景真的出现。
- 再根据共同部分去抽 composable。
这样抽出来的东西，通常更贴近真实复用，而不是凭感觉设计出来的“未来接口”。
结语
composable 真正的价值，不是让代码看起来更高级，而是让逻辑边界更清楚。该抽的时候抽，能明显减轻页面负担；不该抽的时候硬抽，只会把业务理解成本转移到别的文件里。对我来说，能不能让后来接手的人一眼看懂，始终比“抽得优不优雅”更重要。