Vue 逻辑复用的多种方案对比！

前言

这一章不讲"工具怎么配"，而是讲：

怎样把一个 Vue 项目，从"能跑"建设成"长期可维护的工程"

如果你现在：

• 新人一进项目就懵
• 老人一改代码就怕
• 分支一多就乱
  那问题99% 不在 Vue，在工程化。

工程化不是"配置多"，而是降低长期协作成本

一、项目初始化：第一天就决定了三年后的命运

1️⃣ 初始化不是 npm create 就结束了

初始化阶段必须做 3 件事：

✅ 1. 明确技术栈边界

在 README 里写清楚（不是写给自己，是写给半年后的新人）：

• Vue 3 + TypeScript（是否强制）
• 构建工具：Vite
• 状态管理：Pinia
• 路由：Vue Router
• UI 库（是否允许多个）
• 是否允许 Options API

👉 "能不能用"要在项目第一天定死

✅ 2. 初始化即开启严格模式

// tsconfig.json
"strict": true

很多团队失败在一句话：

"先宽松点，后面再收紧。"

现实是：永远不会收紧。

✅ 3. 初始化就接入工程工具

• ESLint
• Prettier
• Git hooks（husky）
• commit 规范

👉 工程工具不是"后补"，是"地基"

二、目录结构规范：不是好看，是为了"找得到"😤

2️⃣ 推荐目录结构（中大型项目）

src/
├─ app/                # 应用级配置（路由、store 注册）
├─ assets/             # 静态资源
├─ components/         # 通用组件（无业务）
├─ features/           # 业务模块（强烈推荐）
│   ├─ user/
│   │   ├─ pages/
│   │   ├─ components/
│   │   ├─ composables/
│   │   └─ api.ts
│   └─ order/
├─ composables/        # 全局通用逻辑
├─ stores/             # Pinia store
├─ services/           # API 请求封装
├─ utils/              # 纯工具函数
├─ styles/             # 全局样式
└─ main.ts

3️⃣ 核心原则（比结构更重要）

❌ 不推荐

• components 里放业务组件
• utils 里写业务逻辑
• 页面到处 import 各种东西

✅ 推荐

"功能相关的代码，放在一起"

👉 Feature-based 结构 > 技术类型结构

三、环境区分：这是"线上事故高发区"⚠️

4️⃣ 不同环境至少要区分这些

• API Base URL
• 是否开启 mock
• 是否打印日志
• 是否开启 devtool
• 第三方 key（统计 / Sentry）

5️⃣ 推荐做法（Vite）

.env
.env.development
.env.test
.env.production

const baseURL = import.meta.env.VITE_API_BASE

⚠️ 约定：

• 所有自定义变量必须 VITE_ 开头
• 不要在代码里写死环境判断

6️⃣ 环境策略最佳实践

❌

if (process.env.NODE_ENV === 'production') {}

✅

if (import.meta.env.VITE_ENABLE_LOG)

👉 环境不是"if else"，而是"配置驱动"

四、代码规范：不是"限制"，是"减少无意义争论"😅

7️⃣ 必须统一的规范（强制）

✅ ESLint（逻辑正确性）

• no-unused-vars
• no-implicit-any
• no-floating-promises
• 禁止 any（可白名单）

✅ Prettier（格式）

• 不讨论缩进、引号
• 保存即格式化

👉 代码评审不该讨论格式

8️⃣ 命名规范（比你想象的重要）

• 组件：PascalCase
• composable：useXxx
• store：useXxxStore
• 文件名：kebab-case

❌ handleData2

✅ fetchUserList

9️⃣ 强烈建议的约束规则

• 禁止在模板中写复杂表达式
• setup 超过 150 行必须拆
• 禁止跨 feature 直接 import 内部文件

👉 规范是为了"逼你拆模块"

五、自动化工具：把"人为失误"交给机器 🤖

🔟 Git Hooks（必须）

pre-commit

• ESLint
• TypeScript 检查
• 单元测试（可选）

commit-msg

• 规范 commit message（conventional commits）

feat: 支持用户列表分页
fix: 修复登录态丢失问题

1️⃣1️⃣ CI（工程成熟的标志）

至少要有：

• lint
• type check
• build

进阶：

• 单元测试
• E2E
• 覆盖率门禁

👉 CI 不是为了卡人，是为了卡事故

六、你真的需要的不是"更多工具"，而是"工程纪律"😤

工程化失败的常见原因

• 工具配了，但没人遵守
• 规范写了，但不 enforce
• 架构设计靠口头约定

👉 没有自动化兜底的规范 = 建议

七、一句话工程化总结（非常重要）

• 工程化 = 降低协作成本
• 目录结构 = 认知地图
• 规范 = 自动化约束
• 工具 = 把"重复 + 易错"交给机器