分仓的痛，只有全栈开发者懂
分仓的痛，只有全栈开发者懂
掘金上最近有个话题特别火——”NestJS + Monorepo 越来越流行了”。评论区清一色的”真香”，点赞数蹭蹭往上涨。
但我看完之后的第一反应是：等等，Monorepo 不是 Google 十年前就在用的东西吗？怎么现在才火？
你要说工具链成熟了——Turborepo 2022 年就发布了，Nx 更早。你要说概念新——Monorepo 这个词都快被念出包浆了。那到底是什么变了？
答案很简单，但大多数人没说到点子上：不是 Monorepo 变了，是开发者变了。
准确地说，是 AI 编程让”一个人写全栈”从理论变成了现实，而当你一个人同时写前端和后端的时候，两个仓库就成了最大的绊脚石。
分仓的痛，只有全栈开发者懂
想象一下这个场景：你在写一个 API 接口，改了返回字段的类型。然后你需要：
- 切到前端仓库
git pull一下确保最新- 找到调用这个接口的地方
- 改类型定义
- 改调用逻辑
- 测试
- 提交
- 切回后端仓库
这还是最理想的情况——你记得前端仓库在哪个目录。实际情况往往是，你打开终端，cd 了三次没找对路径，然后发现前端仓库还停在上周的分支上，得先 git stash 再 git checkout，心态已经崩了一半。
一个字段的改动，八个步骤，跨两个仓库。 如果你一天改十个接口呢？
这就是为什么老一辈程序员能忍分仓——因为他们本来就是分工的。前端写前端，后端写后端，各管各的仓库，互不干扰。但现在不一样了。
AI 编程改变了一切
2025 年之后，一个肉眼可见的趋势是：越来越多的开发者开始一个人写全栈。
不是因为他们突然变强了（当然也有），而是因为有了 Claude Code、Cursor 这些 AI 编程工具。后端不太熟？让 AI 帮你写。数据库 SQL 不确定？让 AI 查一下。以前一个人搞全栈得是”全干工程师”，现在有了 AI 辅助，门槛低了不止一个量级。
你去 GitHub 上看看就知道了——2026 年以来，用 Monorepo 起步的新项目数量几乎翻了一倍。更有意思的是，这些项目的主力军不再是大厂团队，而是 5 人以下的小团队和单兵作战的独立开发者。
以前 Monorepo 是大厂才用得起的奢侈品，现在反过来了——小团队才是最大的受益者。
为什么？因为大厂有专门的 DevOps 团队来维护多仓库的 CI/CD 流水线，有专门的平台组来做跨仓库的依赖管理。这些成本对大厂来说可以接受。但对一个 3 人团队或者独立开发者来说，维护两个仓库的构建、部署、版本同步——光想想就头大。
Monorepo 不是技术变了，是使用技术的人变了。
一个人做饭，你需要几个厨房？
说了半天分仓的痛，Monorepo 到底好在哪？打个比方你就懂了。
分仓就像你家有两个独立厨房——一个中式厨房，一个西式厨房。中式厨房有炒锅和蒸笼，西式厨房有烤箱和面包机。听起来很专业对吧？
问题来了：你想做一道”芝士焗饭”。你得先在中式厨房炒好饭，端着锅跑到西式厨房去铺芝士、进烤箱。做完之后两边都要洗，调料瓶也得备两套——因为两个厨房的冰箱不共享。
Monorepo 就是一个大厨房。 所有食材在同一个冰箱，所有工具在同一个台面。你想做什么菜，转个身就能拿到需要的东西。不用跑来跑去，不用维护两套调料。
具体到代码层面：
- 类型共享：前后端用同一套 TypeScript 类型定义，改一处全局生效。不会出现”后端改了字段名但前端还在用旧的”这种经典翻车。
- 原子提交：一个 PR 同时改前端和后端，reviewer 能看到完整的变更上下文。不用在两个 PR 之间跳来跳去猜”这两个改动是配套的吗”。
- 统一工具链：一套 ESLint 配置、一套 CI 流水线、一套部署脚本。维护成本直接砍半。
你可能会说：大型项目放一个仓库，git clone 得等半天吧？没错，这确实是 Monorepo 的经典问题。但 2026 年的工具链已经解决了大部分痛点——Turborepo 的远程缓存让你只构建改动的部分，git sparse-checkout 让你只拉需要的目录。对于个人项目和小团队，这些问题基本不存在。
决策树：你到底该不该用 Monorepo？
别急着”真香”，先做一道选择题。答错了，Monorepo 会从蜜糖变成砒霜。
场景一：独立开发者或 5 人以下团队，前后端都用 TypeScript → 闭眼选 Monorepo。类型共享、统一工具链、原子提交——每一条都是在帮你省命。NestJS + React/Next.js + Turborepo，这套组合拳打出去，开发体验直接起飞。工具选对了，一个人能打出一个班的输出。
场景二：前后端使用不同语言（比如 Java 后端 + React 前端） → 老老实实分仓。Monorepo 的核心红利是语言统一带来的类型共享。前后端连语言都不一样，放一起就像把火锅和烧烤塞进同一个锅——不是不能吃，是没必要。
场景三：已有大型分仓项目，考虑迁移 → 别。认真的。架构迁移最危险的不是技术风险，是沉没成本幻觉——你以为迁完就好了，其实迁移本身会制造更多的问题。 CI/CD 要重写、权限要调整、团队习惯要重建。除非分仓已经严重拖后腿，否则别折腾。
场景四：超过 20 人的团队 → 想清楚你有没有配套的基础设施团队。Monorepo 在大团队里会带来代码所有权模糊、构建时间膨胀、合并冲突频率飙升。大厂用 Monorepo 不是因为它好，是因为他们养得起一个团队专门伺候它。你养得起吗？
不用切仓库，真的很爽
写到这里，我不打算假装客观了。
作为一个经常用 Claude Code 同时写前端和 API 的人，Monorepo 给我最大的感受就一个字：爽。
改了后端接口的返回类型，前端的类型报错立刻就弹出来——不用切仓库，不用手动同步，编辑器直接告诉你哪里要改。写完一个功能，一个 git commit 就搞定——前端、后端、共享类型，全在一个提交里，回滚也是一把梭。
让 AI 帮我改代码的时候更明显。我可以直接说”把这个接口的返回字段从 name 改成 displayName，前后端一起改”。如果是分仓，AI 只能看到当前仓库的代码，另一个仓库的改动你得自己跑过去处理。
Monorepo 不是银弹——它解决不了你的产品设计问题，解决不了你的技术债务，也解决不了你的拖延症。但它解决了一个很具体的问题：当一个人同时写前端和后端的时候，不用在两个仓库之间切来切去。
有人说这只是个小痛点，不值得为此改架构。
但写代码的人都知道：打断心流的不是难题，是琐事。 切仓库、同步类型、对齐版本——每一件都不难，但每一件都在打断你的思路。Monorepo 消灭的不是技术难题，而是那些让你从”心流状态”跌回”杂务模式”的摩擦力。
2026 年，越来越多的人一个人在写全栈。
而一个人的战斗力，取决于他能在心流里待多久。