Vue 项目的复杂度通常不是从组件数量开始失控，而是从业务逻辑散落在页面、组件和 store 之间开始失控。2026 年的 Vue 团队更需要关注组合式架构：哪些逻辑应该抽成 Composable，哪些状态应该留在组件内，哪些能力应该沉淀为业务模块。
Composable 不是万能抽象
一个常见误区是把所有逻辑都抽成 useXxx。这样短期看起来复用率变高，长期却容易出现隐式依赖、生命周期混乱和测试困难。更稳妥的做法是把 Composable 分成三个明确层级：
第一层：基础能力 Composable（Infrastructure）
这一层只处理稳定的技术问题，与业务无关。典型例子：
useRequest：封装请求取消、重试、缓存和竞态处理useDebounce/useThrottle：输入防抖和节流useIntersectionObserver：元素可见性监听useEventListener：事件绑定和自动清理useMediaQuery：响应式断点检测
基础能力层的特征是高复用、零业务耦合、单向依赖。它们不引用任何业务类型或领域逻辑，可以在不同项目间直接移植。
第二层：业务流程 Composable（Domain）
这一层承载明确的领域规则，是对业务逻辑的结构化表达。典型例子：
useProductSearch：封装商品搜索的查询、筛选、排序和分页逻辑useOrderFlow：封装下单流程的状态机（购物车→地址→支付→确认）usePermission：封装当前用户的权限校验逻辑useFormValidation：封装特定业务表单的校验规则
领域层的特征是明确的业务边界、可独立测试、依赖方向单向指向基础层。这一层的 Composable 通常包含业务特有的类型定义和常量。
第三层：页面适配 Composable（Adapter）
这一层负责把业务流程转换成当前页面或组件需要的状态形态。典型例子：
useProductListPage：组合useProductSearch+usePagination+ 路由参数useDashboardData：聚合多个数据源的 loading/error/data 状态useUserProfile：组合用户信息、权限和编辑状态
适配层的特征是生命周期绑定到具体页面、组合多个领域 Composable、暴露视图专用状态。它们通常不会被其他页面复用。
三层之间保持单向依赖：适配层 → 领域层 → 基础层。这个约束让项目规模变大后仍然容易追踪依赖方向。
状态边界要提前设计
Vue 的响应式系统足够灵活，但灵活不等于可以随处共享状态。2026 年的最佳实践是将状态按作用域分为四个等级：
L1：组件内部状态（Component State） 适用于表单输入、弹窗开关、当前 tab、局部 loading 等。特点是生命周期短、依赖范围明确。使用 ref 或 reactive，不需要也不应该被外部访问。
L2：共享组件状态（Shared Component State） 适用于父子组件或兄弟组件之间的状态传递。首选方案是 defineProps + defineEmits，其次是 provide/inject。避免一上来就用全局 store。
L3：模块级状态（Module State） 适用于一个业务模块内部多个页面共享的状态。典型的实现是创建一个模块级别的 Composable，内部使用 ref，通过 provide/inject 或模块单例暴露。只有当多个业务入口都依赖同一份事实来源时，才需要进入这个层级。
L4：全局状态（Global State） 适用于跨模块的共享状态，如用户信息、全局配置、主题设置。使用 Pinia store，但要严格控制数量——一个健康的中大型项目，全局 store 的数量通常不超过 5 个。
关键原则：状态能留在组件内的就不要上升，能模块化的就不要全局化。 每次提升状态的作用域，都意味着更多的耦合和更复杂的测试。
副作用管理：effect 不是万能的
Vue 的 watch 和 watchEffect 是强大的工具，但也很容易被滥用。2026 年比较成熟的实践是：
- watch 用于响应式同步：当 A 变化时更新 B（如路由参数变化时重新请求数据）
- watchEffect 用于调试和简单同步：不适合承载复杂业务逻辑
- 业务副作用放在 Composable 的方法里：显式调用比隐式触发更容易追踪和测试
一个实用的判断标准：如果 watch 的回调超过 10 行，或者包含了异步操作和条件分支，那就应该考虑把它重构为一个显式的 Composable 方法。
测试策略
组合式架构最大的工程收益之一是可测试性的大幅提升。推荐的测试金字塔：
- 单元测试（70%）：针对领域 Composable 的纯逻辑测试。因为脱离了组件上下文，可以直接用
@vue/test-utils或单纯调用 Composable 函数来验证。这是投入产出比最高的测试。 - 集成测试（20%）：验证多个 Composable 组合后的行为，以及它们与 Pinia store 的交互。
- 组件测试（10%）：只覆盖关键交互路径，不需要为每个组件都写测试。
代码评审时重点关注四个维度：依赖方向是否正确（单向）、状态归属是否合理（四层模型）、副作用入口是否显式、Composable 的输入输出是否明确。
迁移策略：从混乱到有序
如果你的 Vue 项目已经积累了大量混乱的 mixin、过度使用的 store 和散落的业务逻辑，不要试图一次性重构。更务实的迁移路径是：
- 先抽基础层：把纯技术工具函数抽取为基础 Composable，这是风险最低的一步
- 再梳理领域层：每次修改一个业务模块时，顺手把相关逻辑封装为领域 Composable
- 最后整合适配层：在新页面中使用适配层模式，老页面逐步迁移
- 每个阶段都写测试：测试是重构的安全网，没有测试不要做大规模抽象
小结
Vue 2026 的核心竞争力不只是语法简洁，而是能否把复杂业务拆成稳定、可测试、可演进的组合单元。三层 Composable 架构（基础→领域→适配）加上四级状态模型（组件→共享→模块→全局），为大型 Vue 项目提供了清晰的治理框架。关键在于：Composable 服务于业务边界，而不是成为新的全局工具箱。