常见架构模式

是什么

架构模式回答：代码怎么分层、目录怎么组织、职责怎么划分。不解决它，项目超过 20 个文件后就会陷入「改一处崩三处」的泥潭。

对个人项目，最实用的三个模式是：分层架构、组件化、模块化。它们不互斥，通常一起用。

三种模式

1. 分层架构

把代码按职责切成几层，每层只干一类事，上层调用下层，下层不知道上层。

┌─────────────────────────┐
│  视图层  Vue 组件        │  只管展示和交互
├─────────────────────────┤
│  逻辑层  composables/    │  业务规则、状态编排
├─────────────────────────┤
│  数据层  api/            │  请求后端、管理缓存
└─────────────────────────┘

• 优点：职责清晰，换 UI 框架不动业务，接口统一收口
• 缺点：小项目里是过度设计，层间传参有样板代码
• 适用：只要超过「几个页面 + 几个接口」，就值得分

2. 组件化

把界面拆成独立、可复用的组件（按钮、卡片、弹窗……），像搭积木一样拼页面。

• 优点：复用、隔离（改一个组件不牵连别人）、可单测
• 缺点：拆分粒度需要经验——拆太碎反而到处传参
• 粒度经验：一个组件只做一件事；超过约 300 行就该考虑拆；同一段 UI 出现第二次就抽组件

3. 模块化（目录按功能划分）

目录按「业务功能」分，而不是按「文件类型」分。

❌ 按类型（反例）          ✅ 按功能（推荐）
src/                      src/
├── components/  (20个)   ├── user/
├── views/       (10个)   │   ├── UserList.vue
├── api/                  │   ├── UserDetail.vue
├── stores/               │   ├── api.ts
└── utils/                │   └── store.ts
（改一个功能要跳 4 个目录） ├── order/
                          └── shared/
                             （真正跨功能的才放这里）

• 优点：一个功能的所有代码在一起，删功能 = 删一个目录
• 缺点：需要克制——shared/ 很容易变成垃圾抽屉

怎么选

个人项目推荐组合拳：按功能划分目录 + 目录内分三层（组件 → composable → api）+ 界面拆组件。

// 典型的层间配合
// api/user.ts —— 数据层：只有请求
export const getUser = (id: number) => http.get(`/users/${id}`)

// composables/useUser.ts —— 逻辑层：状态与规则
export function useUser(id: number) {
  const user = ref<User | null>(null)
  const loading = ref(false)
  const load = async () => {
    loading.value = true
    user.value = await getUser(id)
    loading.value = false
  }
  return { user, loading, load }
}

// UserDetail.vue —— 视图层：只管展示
const { user, loading, load } = useUser(route.params.id)

反模式：utils 垃圾抽屉

所有「暂时不知道放哪」的代码都塞 utils/，三个月后没人敢动。规则：两个以上功能都要用的才进 shared/，其余留在功能目录里。