北京
一个电商项目分三库，前端Next.js、移动端React Native、后端NestJS各占一个仓库，三个月后你还笑得出来吗？复制粘贴工具函数、定义三份不同的用户接口、升级React要改三处——这根本不是什么整洁架构，更像是同一张图纸抄了三遍还越抄越不一样。
多仓库的“干净”是纸面上的：每个仓库有自己的依赖树，自己的CI流水线，自己的Git历史。当项目还小，这仿佛是教科书级的解耦。可一旦团队开始并行推进，五个棘手的维护成本就浮出来。
第一件事，代码重复变成默认操作。写一个formatPrice(price)帮你格式化成“$49.99”，前端要用，移动端也要用，下一个人懒得跨仓库引，直接copy过去。从此两个函数各自演化，一个改了精度另一个还是旧的。原文里的场景就是如此：formatPrice被复制后，版本悄悄掉队。
第二件事，类型定义一人一个样。后端定了User接口：id、name、email，前端自己再写一份，移动端又来一份。后来谁给User加了个avatar字段，但只更新了后端那版。这时候三个应用对“用户长什么样”各说各话，运行时bug就是这种不声不响的错位埋下的。
第三件事，依赖升级成倍重复。web/package.json, mobile/package.json, api/package.json三份清单独立维护。想统一升级React或者TypeScript，一样的操作得执行三次，还保不齐某个仓库偷偷停在旧版本，最后包版本参差不齐。
第四件事，CI/CD流水线也裂变。每个仓库都要有自己的构建、测试、部署配置和环境变量，仓库一多，这些基础设施的维护量乘上去，变成持续的隐性开销。
第五件事，重构像跨仓库捉迷藏。想把Product重命名为CatalogProduct，你得翻遍所有仓库改动，遗漏一个就是线上事故。原文提到这点的最后一句虽然被截断，但方向很明确——跨仓库改名就是在给未来的自己挖坑。
monorepo正是为解决这种碎片化而生的：所有应用和共享包存在一个仓库里，共用一份依赖管理，一个CI管道。问题是，大仓慢也是出了名的。Turborepo要做的，就是在monorepo的结构上把速度捡回来。至于具体怎么用缓存和任务编排让构建飞起来，我们另开一篇细聊。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
