一、Monorepo 相关
- 什么是 Monorepo？它有哪些优缺点？
Monorepo 是一种项目管理方式，指将多个相关项目（或包）的代码存储在一个单一的代码仓库中进行管理。例如，一个前端团队的组件库、工具库、业务项目等可以放在同一个仓库里。
优点：
- 代码共享便捷：不同项目间可直接引用代码（如公共组件、工具函数），无需通过 npm 发布再安装
- 依赖管理统一：避免多仓库中相同依赖版本不一致的问题，减少 “版本地狱”
- 开发流程高效：修改公共代码后，所有依赖它的项目可实时感知并测试，无需跨仓库同步
- 版本协同简单：多项目版本迭代可统一规划，避免跨仓库版本兼容问题
- 团队协作透明：所有项目代码在同一仓库，便于新人了解整体架构，团队成员也能快速知晓其他项目动态
缺点：
- 仓库体积过大：随着项目增多，仓库代码量和历史提交记录会急剧膨胀，拉取和克隆速度变慢
- 权限管理复杂：难以精细化控制不同成员对仓库内不同项目的访问权限（如只允许某成员修改 A 项目，禁止修改 B 项目）
- 构建成本增加：仓库整体构建时间可能变长，需要工具支持 “按需构建”
- 学习成本提高：新人需要熟悉仓库内所有项目的结构和关联关系，初期上手难度较大
- Monorepo 和 Multi-repo 有什么区别？适用场景分别是什么？
区别主要体现在仓库数量、代码共享方式、依赖管理等方面：
| 对比维度 | Monorepo | Multi-repo（多仓库） |
|----------------|---------------------------|-----------------------------------|
| 仓库数量 | 单一仓库管理所有项目 | 每个项目对应一个独立仓库 |
| 代码共享 | 直接内部引用 | 通过 npm 包发布 / 安装或 git 子模块 |
| 依赖管理 | 统一管理，版本一致 | 各仓库独立管理，版本可能冲突 |
| 权限控制 | 精细化控制难度大 | 可针对单个仓库设置权限 |
| 仓库体积 | 随项目增多逐渐庞大 | 单个仓库体积较小 |
适用场景：
- Monorepo：
- 项目间关联性强（如同一产品的前端、后端、组件库）
- 需要频繁共享代码（如公共组件库与业务项目）
- 团队规模中等，且需要强协作（如同一部门内的多个子项目）
- 追求开发效率和版本协同（如组件库与依赖它的业务项目同步迭代）
- Multi-repo：
- 项目间独立性高（如公司不同产品线，几乎无代码交集）
- 需要严格的权限隔离（如开源项目与内部私有项目）
- 团队规模大且分散（如跨公司协作的项目）
- 单个项目体积庞大（如大型后端服务，单独仓库可降低构建成本）
- 如何在 Monorepo 下实现包间依赖和版本管理？
- 包间依赖实现：
- 通过 “工作区（Workspace）” 机制：主流包管理工具（pnpm、npm、yarn）均支持工作区配置，在根目录的配置文件（如 pnpm-workspace.yaml）中定义子项目路径，子项目可直接通过包名引用其他子项目（如 import { utils } from '@my-org/utils'），无需发布到 npm
- 软链接映射：工具会自动在子项目的 node_modules 中创建对其他子项目的软链接，实现本地实时引用
- 版本管理：
- 统一版本号：所有子项目使用相同版本号（如均为 1.0.0），适合关联极强的项目（如同一产品的不同模块）
- 独立版本号：子项目各自维护版本号（通过自身 package.json 的 version 字段），适合独立性较强的子项目（如组件库和工具库）
- 借助工具自动化：使用 Changesets、Lerna 等工具，自动检测子项目变更，根据依赖关系生成版本更新建议，并批量执行版本升级和发布
二、pnpm 相关
- pnpm 和 npm/yarn 有什么区别？为什么 Monorepo 推荐用 pnpm？
- pnpm 和 npm/yarn 的核心区别：
- 依赖存储方式：
- npm（v3+）和 yarn 采用 “扁平 node_modules”，会将依赖的依赖提升到顶层，可能导致版本冲突（如同一依赖的不同版本被覆盖）
- pnpm 采用 “内容寻址存储”：依赖被存储在全局仓库（.pnpm-store），项目 node_modules 中通过硬链接指向全局存储，且子依赖不会被提升，严格遵循依赖树结构，避免版本冲突
- 安装速度：pnpm 安装速度通常快于 npm 和 yarn，因为依赖复用全局存储，避免重复下载，且硬链接比复制文件更高效
- 磁盘占用：pnpm 因依赖复用，磁盘占用远低于 npm/yarn（相同依赖仅存储一次）
- 安全性：pnpm 的依赖隔离更严格，避免 npm/yarn 中 “依赖劫持” 风险（即非声明依赖的包无法被引用）
- Monorepo 推荐用 pnpm 的原因：
- 工作区支持更高效：pnpm workspace 对多包管理的支持更成熟，配置简单（通过 pnpm-workspace.yaml 定义子项目），且包间依赖链接速度快
- 依赖隔离更严格：在 Monorepo 中多项目依赖复杂，pnpm 的非扁平 node_modules 可避免不同项目的依赖版本冲突
- 磁盘空间占用少：Monorepo 中可能存在大量重复依赖，pnpm 的全局存储 + 硬链接机制可大幅节省磁盘空间
- 脚本执行更灵活：支持通过 pnpm --filter 过滤指定项目执行脚本（如只构建某一子项目），适配 Monorepo 按需操作的需求
- pnpm workspace 的原理和优势是什么？
- 原理：
pnpm workspace 通过在根目录的 pnpm-workspace.yaml 配置文件中声明子项目路径（如 packages: ['packages/*', 'apps/*']），将多个子项目纳入统一管理。当安装依赖时，pnpm 会在根目录的 node_modules 中创建 “虚拟存储”，并通过软链接将子项目及其依赖映射到各自的 node_modules 中。子项目间引用时，直接通过包名指向对应子项目的软链接，实现本地实时依赖，无需发布到 npm 仓库。
- 优势：
- 包间引用零成本：子项目可直接引用其他子项目，修改后实时生效，无需手动发布和安装
- 依赖安装高效：所有子项目的依赖会统一分析并安装，避免重复下载，且利用 pnpm 的硬链接机制节省空间
- 版本管理灵活：支持子项目独立版本或统一版本，且可通过 pnpm update 批量更新依赖
- 脚本批量执行：可在根目录通过 pnpm run <script> 批量执行所有子项目的同名脚本，也可通过 --filter 指定项目执行
- 如何用 pnpm 管理多个包的依赖和脚本？
- 依赖管理：
- 安装公共依赖：在根目录执行 pnpm add <package> -w（-w 表示安装到根目录的 node_modules，供所有子项目共享）
- 安装子项目私有依赖：进入子项目目录执行 pnpm add <package>，或在根目录执行 pnpm add <package> --filter <project-name>（ 为子项目 package.json 中的 name 字段）
- 安装包间依赖：若子项目 A 依赖子项目 B，直接在 A 的 package.json 中声明 dependencies: { "B": "workspace:*" }，执行 pnpm install 后自动创建链接（workspace:* 表示引用工作区中 B 的最新版本）
- 更新依赖：根目录执行 pnpm update 更新所有依赖；执行 pnpm update <package> --filter <project-name> 更新指定子项目的依赖
- 脚本管理：
- 执行所有子项目脚本：在根目录执行 pnpm run <script-name>（如 pnpm run dev），会自动执行所有子项目中定义的 dev 脚本
- 执行指定子项目脚本：通过 --filter 过滤，如 pnpm run build --filter <project-name> 只执行某子项目的 build 脚本
- 按依赖关系执行：若子项目 B 依赖 A，可通过 pnpm run build --filter <B>...（... 表示包括依赖链）先构建 A 再构建 B
- 根目录统一脚本：在根目录 package.json 中定义脚本（如 "build:all": "pnpm run build --filter \"./packages/*\""），简化常用操作
三、Turborepo 相关
- Turborepo 的核心原理是什么？它如何提升 Monorepo 的构建效率？
- 核心原理：
Turborepo 是一个针对 Monorepo 的构建工具，基于 “任务依赖图” 和 “增量构建” 实现高效管理。它通过分析项目间的依赖关系（如 A 依赖 B，则构建 A 前需先构建 B）生成任务依赖图，再结合缓存机制，只执行有变更的任务及依赖它的任务，避免重复构建。
- 提升构建效率的方式：
- 增量构建：记录每个任务的输入（如代码文件、依赖版本、环境变量），若输入未变则直接复用缓存结果，无需重新执行
- 并行执行：根据任务依赖图，在不冲突的任务间（如无依赖关系的两个子项目构建）启用并行执行，充分利用 CPU 资源
- 任务过滤：支持通过命令过滤指定任务（如只构建某一项目）或只执行受变更影响的任务
- 远程缓存：可将缓存上传到远程存储（如 AWS S3、Vercel 远程缓存），团队成员或 CI 环境可共享缓存，避免重复构建
- Turborepo 的缓存机制是如何工作的？如何配置依赖关系？
- 缓存机制工作流程：
- 缓存键生成：为每个任务（如 build、test）生成唯一缓存键，基于输入内容（代码文件哈希、依赖任务的输出哈希、环境变量、命令参数等）
- 缓存存储：执行任务后，将输出结果（如构建产物、日志）与缓存键关联，存储在本地（.turbo 目录）或远程缓存
- 缓存命中判断：下次执行同一任务时，生成新缓存键与已有缓存对比，若一致则直接使用缓存结果；若不一致则重新执行任务并更新缓存
- 依赖关系配置：
在根目录 turbo.json 中通过 pipeline 字段配置任务依赖，例如：
同时，在 package.json 中通过 dependencies 声明项目间的依赖关系（如 "dependencies": { "@my/pkg": "workspace:*" }），Turborepo 会自动识别并关联任务依赖。
- 在实际项目中，如何用 Turborepo 优化 CI/CD 流程？
- 配置远程缓存：在 CI 环境中配置 Turborepo 远程缓存（如 Vercel Cache、S3），使不同 CI 运行实例可共享缓存，避免重复构建（例如：开发者本地构建后上传缓存，CI 拉取缓存直接使用）
- 按需执行任务：通过 turbo run <task> --filter=[...] 在 CI 中只执行受变更影响的任务。例如，推送代码后，Turborepo 自动检测变更的子项目，只构建、测试该项目及依赖它的项目，减少 CI 执行时间
- 并行任务调度：在 CI 中利用 Turborepo 的并行执行能力，同时运行多个无依赖的任务（如不同子项目的 lint），缩短整体流程耗时
- 缓存输出产物：将构建产物（如 dist 目录）通过 Turborepo 缓存保留，在部署阶段直接从缓存提取，避免重复构建
- 集成环境变量：在 turbo.json 中声明影响构建的环境变量（如 env: ["NODE_ENV"]），确保环境变化时重新执行任务，避免缓存不一致问题
四、实践与场景题
- 你在 Monorepo 项目中遇到过哪些依赖冲突问题？如何解决？
常见依赖冲突问题及解决方法：
- 问题 1：不同子项目依赖同一包的不同版本
- 现象：子项目 A 依赖 lodash@4.17.0，子项目 B 依赖 lodash@4.17.20，安装时出现版本冲突提示
- 解决：通过根目录 package.json 的 pnpm.overrides（pnpm）或 resolutions（yarn）强制统一版本，例如：
- 问题 2：子项目依赖的包与根目录公共依赖版本冲突
- 现象：根目录安装了 react@18，子项目依赖 react@17，导致运行时报错（如 hooks 不兼容）
- 解决：优先使用根目录公共依赖，删除子项目的私有依赖（通过 pnpm remove react --filter <project>），或升级子项目到兼容版本
- 问题 3：间接依赖版本冲突（如 A 依赖 B@1.0，C 依赖 B@2.0）
- 现象：安装后 node_modules 中同时存在 B@1.0 和 B@2.0，导致代码引用混乱
- 解决：使用 pnpm why <package> 查看依赖来源，评估是否可升级 A 到兼容 B@2.0 的版本；若不可升级，接受多版本共存（pnpm 会通过隔离目录存储不同版本，避免冲突）
- 如何在 Monorepo 下实现 “只构建受影响的包”？
- 步骤 1：明确依赖关系
通过工具（如 Turborepo、Nx）自动分析子项目间的依赖关系，生成依赖图谱（如 A 依赖 B，B 依赖 C）
- 步骤 2：检测变更内容
- 通过 Git 对比当前分支与基准分支（如 main）的差异，确定修改的文件所属的子项目（如修改了 B 项目的代码）
- 工具（如 Turborepo）会自动识别变更的项目为 “受影响源”
- 步骤 3：定位受影响的包
根据依赖图谱，从 “受影响源” 向上追溯所有依赖它的项目（如 B 变更后，A 因依赖 B 也受影响）
- 步骤 4：执行定向构建
使用工具命令只构建受影响的包，例如：
- Turborepo：turbo run build --filter=...<B>（... 表示包括依赖链）
- pnpm：pnpm run build --filter=<A> --filter=<B>（手动指定受影响项目）
- 关键工具：Turborepo、Nx（自动分析依赖和变更）、changesets（检测变更范围）
- 如果有多个团队协作开发 Monorepo，你会如何做权限和发布管理？
- 权限管理：
当提交涉及对应目录时，自动要求负责人审核
- 基于目录的权限控制：结合代码仓库工具（如 GitLab、GitHub）的 “保护分支” 和 “目录权限” 功能，限制团队只能修改指定子项目目录。例如：
- 团队 1 只能修改 packages/component 目录，无法修改 apps/admin
- 配置目录级别的 PR 审核规则（如修改 packages/core 需核心团队审核）
- 分支策略隔离：采用 “feature 分支按团队划分” 策略，例如团队 1 的分支命名为 team1/feature-xxx，并配置分支保护规则，禁止跨团队分支直接合并到主分支
- 代码所有权声明：在根目录添加 CODEOWNERS 文件，声明各子项目的负责人团队，例如：
- 发布管理：
- 独立发布权限：为每个子项目配置独立的发布权限，只有对应团队可触发该项目的发布流程（如通过 CI 配置，只有团队 1 的成员可执行 pnpm publish --filter @my/component）
- 发布流程标准化：通过工具（如 Changesets）统一发布流程，团队提交代码时需添加 “变更说明”（changeset），明确修改的子项目和变更类型（补丁、 minor、major）
- 版本审核机制：发布前由相关团队交叉审核（如依赖被修改项目的团队审核发布内容），避免破坏性变更影响下游项目
- 发布日志自动化：通过 Turborepo 或 Changesets 自动生成发布日志，记录各子项目的变更内容、负责人和版本号，便于追溯