1. 代码复用能力提升#

多个项目可以直接引用：

1
packages/ui
2
packages/utils
3
apps/web

web 可以直接依赖 ui 和 utils（不用发 npm）

2. 依赖统一管理#

所有项目共享：

• node_modules（pnpm 会优化）
• 版本统一（避免版本地狱）

3. 原子提交（Atomic Commit）#

一次提交可以同时修改：

• 后端 API
• 前端调用
• 类型定义

不会出现“版本不匹配”的问题

4. 提高开发体验#

配合工具：

• pnpm workspace
• turborepo / nx

可以实现：

• 增量构建
• 缓存
• 并行执行

5. 适合中大型项目#

比如：

• 微前端
• 组件库 + 业务项目
• AI 应用(AI-SaaS平台)

目录结构（推荐）#

1
my-monorepo/
2
├── apps/
3
│   └── web/
4
├── packages/
5
│   ├── ui/
6
│   └── utils/
7
├── package.json
8
├── pnpm-workspace.yaml

核心配置#

1
mkdir my-monorepo
2
cd my-monorepo
3
pnpm init

1
packages:
2
  - "apps/*"
3
  - "packages/*"

1
mkdir -p apps/web
2
mkdir -p packages/utils

1
cd apps/web && pnpm init
2
cd ../../packages/utils && pnpm init

1
{
2
  "name": "web",
3
  "dependencies": {
4
    "utils": "workspace:*"
5
  }
6
}

1
export function add(a, b) {
2
  return a + b;
3
}

1
import { add } from "utils";
2

3
console.log(add(1, 2));

1
pnpm install

1
node apps/web/index.js

1
3

1. workspace:* 不是随便写的#

只能用于：

• monorepo 内部依赖

不能发布到 npm（需要替换版本号）

2. node_modules 结构不同#

pnpm 使用： 硬链接 + content-addressable storage

所以：

• node_modules 看起来“奇怪”是正常的
• 不要手动改

3. 依赖提升（hoisting）#

pnpm 默认： 不完全扁平

可能出现：

1
找不到某些包

解决：

1
pnpm add lodash -w

4. 子包必须有 name#

1
{
2
  "name": "utils"
3
}

否则 workspace 无法识别

5. 适合但不简单#

Monorepo 很强，但也带来复杂度：

• 构建系统复杂:所有项目一个仓库,构建起来麻烦,存在性能问题
• CI/CD 更复杂:所有项目共用代码库，依赖多、关联杂，CI不好精准判断哪些需要构建、部署，流水线配置和执行都会更麻烦。
• 权限管理困难:权限管理通常依赖代码托管平台(github,gitlab),粒度太粗. 例如: 程序员A->整个仓库,程序员B -> 整个仓库 如果有敏感业务模块,外包人员接受项目,什么都能看到.