Nuxt 组合式函数最佳实践：从抽离复用到边界治理
Nuxt 的 composables 是提升复用效率的核心能力，但很多项目在“抽离逻辑”过程中，会逐步演变成另一个问题：复杂度从页面文件移动到了 composable 黑盒里，团队理解成本并没有下降。
优秀的 composable 不是“代码更少”，而是“边界更清楚、行为更可预期”。
1. 先明确 composable 的职责
更适合放进 composable 的内容：
- 可复用的状态与行为组合
- 与业务域相关的通用流程
- 对外部能力的轻量封装
不建议放入：
- 大量页面专属一次性逻辑
- 与 UI 紧耦合的细节
- 无法测试和复用的临时代码
2. 设计时先画边界，再写代码
建议从这三个问题开始：
- 这个 composable 面向哪些调用方
- 它的输入输出契约是什么
- 它是否会持有跨页面生命周期状态
提前回答这三点，能避免“越用越重”的复用陷阱。
3. 常见拆分模式
| 模式 | 用途 | 示例 |
|---|---|---|
| 场景型 composable | 封装一条完整业务流程 | useCheckoutFlow |
| 能力型 composable | 封装单一能力 | useClipboard |
| 数据型 composable | 封装获取与缓存策略 | useArticleList |
模式清晰后，目录结构和命名会自然稳定。
4. 失败案例：一个 composable 同时处理请求、权限、UI 与埋点
这种“大一统 composable”短期很方便，长期会出现：
- 调用方无法复用局部能力
- 修改一个逻辑影响多个页面
- 测试粒度过粗，定位困难
可复用不等于可维护。可维护来自合理拆分。
5. 与 Nuxt 生态协同的关键点
在 Nuxt 中，composable 通常会和这些机制协同：
useAsyncData/useFetch- runtime config
- 全局状态与 Pinia
要避免在 composable 里隐式读取过多全局依赖，否则会让调用方难以预测行为。
6. 团队规范建议
- 命名体现业务意图，而非实现细节
- 输入参数尽量显式，减少隐式上下文依赖
- 关键 composable 维护最小示例与契约说明
- 在 code review 中审查“边界清晰度”
这会显著提升多人协作下的稳定性。
7. Checklist：你的 composable 是否健康
- 职责是否单一且可解释
- 输入输出是否明确
- 是否避免隐藏全局副作用
- 是否可被独立测试
- 是否在多个场景中复用而非只在单页使用
8. 结论
Nuxt composable 的价值在于把复用变成资产，而不是把复杂度藏起来。以边界治理为核心来设计，才能在项目增长后仍保持可读、可改、可验证。
进一步阅读：
