Monorepo 工程

monorepo 把多个项目放一个仓库：跨项目原子提交（一次 PR 同时改库与应用不出现版本漂移）、代码复用与重构成本低（全局搜索一键改所有调用方）、统一工具链与 CI 规范、可见性高。代价是仓库体量膨胀（克隆与 CI 变慢，需要按目录的权限治理与增量构建工具）、CI 不加治理会全量构建浪费资源、权限边界模糊代码容易被随意跨界引用。polyrepo 隔离清晰、权限天然分仓、单仓轻快，但跨仓改动要协调版本发布、依赖地狱与复制粘贴泛滥。判断标准：团队规模不大、项目强关联、追求重构效率时 monorepo 收益明显；组织庞大、安全合规要求细粒度权限时需要 polyrepo 或带权限模型的 monorepo 工具。答出原子性与 CI 治理两个关键词即佳。

传统 npm 与 yarn 提升依赖到根 node_modules 扁平化，代码能 import 未在自己 package.json 声明的包（幽灵依赖），一旦上游不再间接依赖它即编译崩溃；提升还会引发同包多版本冲突与不确定提升哪个。pnpm 用符号链接布局：node_modules 里只有直接依赖的链接，真实文件集中存放在 .pnpm 虚拟存储中按版本隔离，未声明的包无法被解析到，天然隔离；peer 依赖与版本冲突也各归其位。workspace 配置上，pnpm-workspace.yaml 声明 packages 目录，内部依赖用 workspace 协议（如依赖名冒号 workspace 星号）链接到源码而非发布版本，联调即改即生效，发布时自动替换为真实版本号。能讲清 .pnpm 布局与 workspace 协议两点即完整。

核心是三件事。任务编排：以 package.json 脚本为节点声明依赖图（turbo.json 定义 build 依赖先 build 加 ^build），拓扑序并行调度，充分吃满多核；增量构建：哈希任务输入（源码、依赖、环境变量、锁文件）判断未变的任务直接跳过，只重跑受影响子图；远程缓存：同哈希产物上传共享存储，CI 与同事机器命中即秒级取回，分支反复构建收益巨大。Nx 在此之上提供代码生成器、依赖图可视化、受影响命令与分布式执行（云侧代理跑任务），治理能力强但约定更重；Turborepo 轻侵入、只管调度与缓存。使用要点：保证任务纯函数性（同样输入产同样输出），否则缓存命中出错；正确声明 inputs 与 outputs，避免漏文件导致误命中。答出依赖图、增量、远程缓存即达标。

固定版本（fixed 与 lockstep）是所有包同版本号一起发，Angular 与 React 这类强耦合套件适用，心智简单但一个包小改也要全员升版；独立版本（independent）按包各自 semver 发布，灵活但消费方要面对组合矩阵，需要 changesets 这类工具记录变更并自动计算版本与依赖联动更新。changesets 工作流：PR 里附变更描述文件（changeset），合并后自动开版本 PR 汇总 bump 类型与依赖更新，CI 发布到 npm，天然融入 monorepo。另有 git 协议依赖（直接引分支）与私有 registry 方案。实践建议：对内基础库收敛版本节奏、对外 SDK 走独立 semver 加 CHANGELOG；发布走 CI 凭证与 npm provenance。能对比两种策略并描述 changesets 流程即优秀。

问题在于「都能 import」不等于「该 import」，没有约束会长出循环依赖与分层倒挂。手段一：静态分析规则，用 eslint 的 import 边界插件或 dependency-cruiser、Nx 的 tag 约束（enforce-module-boundaries）声明包的标签（如 layer 等于 app 或 ui 或 data）与允许的依赖方向，违规在 CI 报错；手段二：架构测试，ts-arch 或 ArchUnit 风格断言分层规则；手段三：目录即边界，apps 与 packages 顶层分离，内部再按域拆分，公开 API 用 index 出口收敛，禁止深路径 import。依赖方向原则：应用依赖库、库之间单向分层（ui 不依赖 app）、跨域只能走接口包。配 CI 检查防劣化。答题给出标签加规则的落地例子与循环依赖的处理（提接口包倒置）即完整。