Monorepo+Turborepo+Next常问问题详解
以下是针对 Monorepo 与 Turborepo 的面试高频问题详解，结合核心原理、性能优化及工具对比，助你系统掌握考点：
一、Monorepo 核心概念与适用场景
- Monorepo vs Multirepo
◦ Monorepo：多个项目共享同一仓库、依赖和版本历史，适合强关联项目（如组件库+应用）。
◦ Multirepo：独立仓库管理项目，适合技术栈差异大的场景，但依赖协同成本高。
◦ 面试重点：解释迁移 Monorepo 的动机（如解决依赖冲突、统一 CI/CD）。
- Monorepo 核心挑战
◦ 依赖管理：避免版本冲突（如 pnpm 的硬链接节省磁盘空间）。
◦ 任务编排：高效执行构建/测试（Turborepo 的并行调度）。
◦ 权限控制：大型团队需细粒度访问控制（Git 子模块或工具链扩展）。
二、Turborepo 核心原理与高频考点
- 任务编排三阶段
◦ 范围界定（Scoping）：
turbo run build --filter=ui… # 仅构建 ui 包及其依赖
通过 --filter 参数按需执行子集任务，避免全量构建。
◦ 并行执行（Parallelization）：
▪ 拓扑排序：按依赖关系确定任务顺序（如先构建依赖包再构建主应用）。▪ 跨任务流水线：允许 lint 和 test 任务重叠执行，突破单任务边界。
◦ 云端缓存（Remote Caching）：
▪ 本地/远程缓存构建结果（如 Vercel 托管），二次构建命中缓存可提速 85%+。
- 配置与性能优化
◦ turbo.json 示例：
{
“pipeline”: {
“build”: { “dependsOn”: ["^build"], “outputs”: [“dist/**”] },
“test”: { “dependsOn”: [“build”], “cache”: false } // 测试不缓存
}
}
dependsOn 定义任务依赖关系，outputs 指定缓存目录。
◦ 缓存失效策略：
▪ 文件哈希变化自动失效，支持 --force 强制跳过缓存。▪ 远程缓存共享：团队协作时 CI 任务复用他人构建结果。
三、Turborepo 对比其他工具
工具 核心优势 局限性 适用场景
Turborepo 极致性能（并行+缓存）、轻量易集成 无内置版本管理 中大型项目、高频构建
Lerna 自动化发包（lerna publish） 性能较差、已停止维护 遗留项目维护
Nx 可视化依赖图、插件生态强大 学习曲线陡峭、配置复杂 企业级复杂架构
PNPM 依赖隔离快、磁盘效率高 任务编排能力弱 基础 Monorepo 管理
注：Turborepo 常与 PNPM 组合使用（如 pnpm + turbo）互补短板。
四、性能优化实战题
- 如何优化 Monorepo CI 时间？
◦ 答案：
▪ 启用 Turborepo 远程缓存，避免重复构建未变更包。▪ 按需执行：turbo run test --filter=...$PR_BRANCH 仅测试改动相关包。▪ 并行执行 + 增量测试（如 Jest --onlyChanged）。
- Turborepo 缓存如何保证一致性？
◦ 答案：
▪ 基于文件内容哈希（如 tsconfig.json、src/**/*.ts）生成缓存 Key。▪ 环境变量可注入缓存 Key（如 env:CI 区分环境）。
五、高频面试问题清单
- 基础概念
◦ 为什么选 Monorepo？列举 3 个优势与挑战。
◦ 解释 Turborepo 的 pipeline 配置作用。
- 原理深入
◦ Turborepo 如何实现任务拓扑排序？
◦ 远程缓存如何同步到本地？描述工作流程。
- 场景设计
◦ 设计一个包含 UI 库、Web App、移动端的 Monorepo，如何安排构建流程？
◦ 若某个包的构建失败，Turborepo 如何跳过后续任务？
- 工具对比
◦ Turborepo vs Nx：在构建速度和生态扩展性上的差异？
◦ 为什么 Turborepo 不处理版本发布？（需结合 Lerna/Changesets 使用）
终极建议：面试前实操一次 pnpm + turbo 项目搭建（参考模板(https://turbo.build/repo/docs/getting-started/create-new)），结合 turbo run build --dry-run 分析任务图。
以下是 Git 在面试和工作中的高频问题详解，涵盖核心原理、解决方案及最佳实践，助你系统掌握版本控制核心技能：
一、冲突处理：多人协作的核心痛点
- 冲突产生原理
• 触发条件：多人修改同一文件的同一代码区域，Git 的三向合并算法（对比本地 HEAD、远程分支、共同祖先）无法自动决策。
• 冲突标记：
<<<<<<< HEAD
本地修改内容
远程仓库内容
commit-hash
- 标准解决流程
1. 拉取最新代码（使用 rebase 减少冲突概率）
git pull --rebase origin main
2. 定位冲突文件
git status # 查看 “Unmerged paths”
3. 手动编辑文件，删除冲突标记并保留正确代码
4. 标记已解决
git add conflict-file.js
5. 完成操作
git rebase --continue # 或 git commit -m “Fix conflicts”
6. 推送更新
git push origin main
工具辅助：
• VS Code：冲突文件高亮显示，支持一键保留本地/远程版本。
• git mergetool：调用 Beyond Compare 等专业工具可视化处理。
- 高级技巧
• 快速选择版本：
git checkout --ours file.js # 保留本地版本
git checkout --theirs file.js # 保留远程版本
• 自动记录解决方案：
git config --global rerere.enabled true # 开启 rerere 功能
- 冲突预防策略
• 开发规范：小步提交（单次提交完成一个功能）、每日 git pull --rebase。
• 分支策略：主分支（main）保护 + 功能分支（feature/xxx）隔离开发。
二、分支管理：高效协作的基石
- 核心策略对比
策略 适用场景 关键命令
Git Flow 企业级多版本并行开发 git flow feature start login
GitHub Flow 持续交付的 SaaS 项目 main 分支直推 + PR 审查
Trunk Based 高频部署的小型团队 直接提交到 main 分支
- 最佳实践
• 分支命名规范：类型/描述（如 feature/user-auth、hotfix/payment-bug）。
• 保护主分支：
◦ 禁止直接推送，强制 PR 审查 + CI 测试通过。
◦ 使用 --no-ff 合并保留分支历史：
git merge feature/login --no-ff
• 定期清理：
git branch -d feature/old # 删除已合并分支
git push origin --delete stale-branch # 删除远程分支
三、版本回退与修复：错误操作的救星
- 回退方案选择
命令 适用场景 风险
git reset 本地提交回退（未推送） 强制覆盖历史（慎用）
git revert 已推送提交的撤销 安全，生成反向提交
git checkout 恢复误删文件 仅限未提交的删除
典型操作：
撤销最近一次提交（保留修改）
git reset --soft HEAD~1
创建反向提交抵消错误
git revert bd61f7a
恢复误删文件
git checkout HEAD – deleted-file.js
- 找回丢失提交
git reflog # 查看操作历史（含已删除提交）
git cherry-pick abc123 # 恢复指定提交
四、仓库异常与性能优化
- 仓库修复
• 损坏对象检测：
git fsck # 扫描损坏对象
git prune --expire now # 清理无效对象
• 终极方案：重新克隆仓库（备份未提交修改）。
- 性能优化
• 大文件处理：
git lfs install # 使用 Git LFS 管理二进制文件
• 浅克隆加速：
git clone --depth 1 # 仅克隆最新版本
五、高频面试问题清单
- 冲突处理
◦ 描述一次你解决的复杂冲突案例？
◦ git merge 和 git rebase 解决冲突的区别？
- 分支策略
◦ 如何设计支持 20 人团队的分支模型？
◦ git reset --hard 和 git revert 的使用场景差异？
- 原理深挖
◦ Git 如何存储一次提交的变更？（回答树对象和提交对象）
◦ 三向合并算法如何避免误判？
Git 的精髓在于 “理解状态转换”：工作区 → 暂存区 → 本地仓库 → 远程仓库的流转机制是解决所有问题的核心框架。面试时结合 git status 的输出解释操作步骤，能显著提升回答可信度。