# 1. Nx Affected 与受影响的命令集在 PR 检查的工程价值 A affected 命令会执行所有项目的所有任务 B Nx affected 沿项目依赖图计算变更影响集，只执行受影响项目及其依赖方的任务，大幅提速 PR 检查 ✓ 正确答案 C affected 不需要基线对比 D 依赖图漏边不影响 affected 正确性
# 2. Git hooks（husky、lint-staged）的提交规范 A pre-commit 中应执行全量测试 B hooks 配置无需入库 C --no-verify 绕过无需任何治理 D husky 管理 Git hooks、lint-staged 只处理暂存文件，配合 commitlint 校验消息格式，形成 pre-commit 快查、CI 全查的分层规范 ✓ 正确答案
# 3. Rush 与 pnpm + Changesets 的取舍 A Rush 与 pnpm+Changesets 是完全相同的方案 B Rush 是集成式治理框架、pnpm+Changesets 是轻量组合式方案，取舍在治理密度、协作流与团队规模 ✓ 正确答案 C pnpm 无法与 Changesets 配合 D Changesets 负责依赖安装
# 4. pnpm workspace 在 Monorepo 包管理与磁盘空间的工程价值 A pnpm monorepo 无法使用单一 lockfile B pnpm workspace 每个包独立安装完整副本 C workspace:* 会安装 registry 最新版 D pnpm workspace 统一解析共享 lockfile，store 与 hard link 让多包共享依赖只存一份，显著节省磁盘并保证版本一致 ✓ 正确答案
# 5. Nx 在大型 Monorepo 的依赖图分析与 CI 优化的工程价值 A Nx 的缓存与依赖图无关 B Nx 用项目图分析依赖、任务图编排顺序、affected 与任务级缓存（可远程复用）优化大型 monorepo 的 CI ✓ 正确答案 C Nx 每次 CI 都全量构建所有包 D Nx 无法检测循环依赖
# 6. Lerna 5+ 在 Monorepo 包发布与版本管理的现代实践 A Lerna 5+ 负责依赖安装与任务编排 B Lerna 无法使用 conventional commits C Lerna 5+ 定位为发布与版本管理（fixed/independent），与 pnpm workspaces、Turborepo 各司其职组合使用 ✓ 正确答案 D Lerna 只能用于 npm
# 7. Turborepo 远程缓存（Vercel Cloud 或自部署 Remote Cache） A Turborepo 按任务输入哈希复用输出，远程缓存让结果跨 CI 共享，Vercel 托管零运维、自部署数据自主，取舍在运维与合规 ✓ 正确答案 B 远程缓存命中无需校验输入声明 C 远程缓存只能存储日志不能存产物 D Turborepo 缓存只能本地使用
# 8. Nx / Turborepo / Lerna 在大型 monorepo 任务编排与缓存的工程价值 A 三者功能完全重叠 B Nx 是框架化平台（依赖图+生成器）、Turborepo 是轻量任务编排与缓存、Lerna 管版本发布，按需求组合选型 ✓ 正确答案 C Turborepo 提供 affected 增量分析 D Nx 没有缓存能力
# 9. Nx 的代码拥有者（CODEOWNERS）与 affected 命令的 CI 加速 A CODEOWNERS 决定构建哪些包 B CODEOWNERS 按路径路由评审、Nx affected 收敛验证范围，两者联动让 PR 的评审面与 CI 验证面都聚焦变更影响域 ✓ 正确答案 C affected 与评审无关 D CODEOWNERS 无法用于 monorepo
# 10. Nx 20 的代码生成与依赖图分析 A Nx 生成器只能创建 React 项目 B Nx 生成器把团队规范固化为脚手架，项目图分析依赖、检测循环与边界约束，实现规范自动化与架构可治理 ✓ 正确答案 C Nx 无法检测循环依赖 D enforce-module-boundaries 只能警告不能拦截
# 11. Turborepo 2 的任务编排与远程缓存 A Turbo 缓存键只包含源码内容 B 远程缓存只能读不能写 C 缓存与 env 声明无关 D turbo.json 的 dependsOn/outputs/env/inputs 决定任务编排与缓存哈希，输入声明不全会导致缓存错误命中或失效 ✓ 正确答案
# 12. Nx 的项目图与受影响任务 在测试与构建产物的协作 A affected:test 只跑被修改包的测试 B Nx 沿依赖图计算受影响的测试与构建范围（含依赖方），任务缓存复用产物，发布链路则用全量验证兜底 ✓ 正确答案 C 构建缓存不参与依赖产物变化 D 受影响分析不能用于构建
# 13. pnpm workspace 与 workspace:* 协议在版本与发布的工程价值 A workspace:* 发布时原样保留在产物中 B workspace 协议只能用于同一个包 C workspace:* 在开发期链接工作区源码、发布时自动转换为 registry 版本范围，需治理发布顺序与依赖环 ✓ 正确答案 D workspace:^ 发布后不转换
# 14. Turborepo 的 turbo.json pipeline 与远程缓存（Vercel Remote Cache） A pipeline 的 dependsOn 决定并行度，与顺序无关 B turbo.json 的 pipeline 声明任务依赖与输出，远程缓存需 login/link 与 token 接入，输入声明不全会导致错误命中 ✓ 正确答案 C 远程缓存无需认证 D outputs 声明与否不影响缓存正确性
# 15. Changesets 的版本管理与发布 A Changesets 的版本由 CI 随机计算 B Changesets 用变更文件驱动 semver 版本计算与 CHANGELOG 生成，version 与 publish 分离，配合 PR 门禁保证变更可追溯 ✓ 正确答案 C 发布时无需处理包间依赖顺序 D changeset 只用于固定版本模式
# 16. Changesets 在语义化版本与 CHANGELOG 生成的工程应用 A 变更文件不影响版本计算 B CHANGELOG 由人工在发布后补写 C Changesets 按变更文件的 bump 级别计算 semver 并自动生成 CHANGELOG，配合 PR 门禁与 CI 发布闭环治理版本 ✓ 正确答案 D breaking change 无需标记
# 17. pnpm 的 workspace.yaml 与 package.json 的 workspaces 配置边界 A pnpm 只读取 package.json 的 workspaces B 包级可以自定义工作区范围 C pnpm-workspace.yaml 只能声明 catalog D pnpm 优先用 pnpm-workspace.yaml 声明工作区（含 catalog 等专属能力），与 package.json workspaces 并存时需保持单一声明源避免漂移 ✓ 正确答案
# 18. Monorepo 中的依赖提升（hoisting） A 传统扁平提升共享依赖但产生幽灵依赖，pnpm 严格布局以声明为真相，工具链需求用 hoist-pattern 白名单放行 ✓ 正确答案 B pnpm 与 npm 的布局完全相同 C hoisting 只影响安装速度 D 幽灵依赖是良性现象
# 19. pnpm workspace 在大型项目构建链的工程价值 A workspace 依赖与构建顺序无关 B 构建工具无法解析符号链接 C workspace:* 定义包间拓扑让构建顺序自动正确并支持源码级联调，配合统一配置与产物治理保证大型构建链确定 ✓ 正确答案 D 幽灵依赖在 pnpm 下不会暴露
# 20. Turborepo 的 pipeline 配置在跨包构建顺序的工程实践 A outputs 声明与跨包消费无关 B ^build 表示本包构建后才构建依赖包 C pipeline 无法表达任务内顺序 D dependsOn 的 ^ 前缀按依赖拓扑先构建依赖包，outputs 声明产物供上层复用，并需平衡并行度与治理循环依赖 ✓ 正确答案
# 21. Monorepo 的包版本同步策略（syncpack、manypkg）的工程价值 A syncpack 统一依赖版本范围、manypkg 同步本地包引用，配合 CI 门禁从声明层治理 monorepo 版本漂移 ✓ 正确答案 B 版本漂移只影响磁盘空间 C range 风格差异不影响安装结果 D 版本同步工具不需要团队规则
# 22. pnpm 的 peerDependency 严格检查在 Monorepo 的工程协作 A pnpm 严格校验 peerDependencies，Monorepo 中宿主依赖单点提供、库包声明 peer，保证共享框架单实例与版本一致 ✓ 正确答案 B peer 版本不满足只在运行时才报错 C 组件库应把 react 放入 dependencies D peerDependencies 与 dependencies 无区别
# 23. Monorepo 的代码所有权（CODEOWNERS）与 PR 评审的工程实践 A CODEOWNERS 只适用于单仓库项目 B 未覆盖路径的代码无需评审 C CODEOWNERS 按路径路由评审到包 owner，配合根级兜底与变更影响方提醒，实现 Monorepo 的责任分权与聚焦评审 ✓ 正确答案 D CODEOWNERS 无法与分支保护协作
# 24. Bun 的 workspaces 与 pnpm 在 Monorepo 的工程性能取舍 A Bun workspaces 安装更快但治理（幽灵依赖、版本统一、脚本白名单）弱于 pnpm，按速度优先或治理优先选型 ✓ 正确答案 B Bun 与 pnpm 的依赖布局完全一致 C bun.lock 与 pnpm-lock.yaml 可混用 D Bun 无法运行 Node 项目
# 25. Monorepo 中共享的构建工具（Vite/Rollup 配置） A 每个包应复制一份完整构建配置 B external 策略与包间依赖无关 C Monorepo 用共享 base 构建配置加包级覆盖，配置作为内部包版本化管理，并统一别名、external 与产物约定 ✓ 正确答案 D 共享配置无法被各包覆盖
# 26. Monorepo 的 Storybook 与组件库发布（changesets） A Storybook 在 monorepo 中只能有一个实例 B Storybook 提供组件开发预览闭环，changesets 以变更文件驱动组件库版本、CHANGELOG 与发布门禁，并与文档站同步 ✓ 正确答案 C changesets 无法处理组件库依赖联动 D 组件库发布无需变更记录
# 27. Monorepo 的 CI 矩阵（按包变更触发）的工程优化策略 A 按变更检测触发对应包的任务，动态生成矩阵，配合增量、缓存与并行，并用 PR 快速门禁与发布全量门禁分层 ✓ 正确答案 B 矩阵变体越多越好 C 缓存与 CI 优化无关 D CI 每次都应全量跑所有包的完整矩阵
# 28. Monorepo 中的工作流（moon 工具）在缓存与编排的现代应用 A moon 只能配合固定打包器 B moon 与 Turborepo 的功能完全相同 C moon 没有缓存能力 D moon 提供项目图编排、全局缓存（跨项目复用）与工具链管理，与 Turborepo/Nx 在生态、托管缓存与治理深度上取舍 ✓ 正确答案
# 29. Yarn 4（Berry）在 PnP 与 node_modules 模式的工程取舍 A PnP 仍会生成 node_modules 目录 B PnP 会加剧幽灵依赖 C Yarn 4 的 PnP 用 .pnp.cjs 解析器实现零 node_modules、高确定性，但工具链需适配，可用 nodeLinker 切换回 node-modules 模式 ✓ 正确答案 D Yarn 4 不支持 node-modules 模式
# 30. Monorepo 的发布策略（fixed/independent 版本模式） A fixed 模式整组共享版本号（简单一致但有发布噪音），independent 各包独立版本（精准但需依赖联动），按包耦合度与发布节奏选型 ✓ 正确答案 B independent 模式无需处理包间版本 C fixed 模式下只有变更的包才 bump D 两种模式不能混合使用
# 31. Turborepo 的 env 白名单与哈希，未声明的环境变量变更为何会导致缓存失效或错误命中，如何设计 env 声明与全局哈希（globalEnv）？ A env 变化不影响 Turbo 缓存 B globalEnv 只影响单个任务 C 任务读取的环境变量未声明会导致缓存错误命中，声明过宽会导致频繁失效，应按最小白名单设计 env 与 globalEnv ✓ 正确答案 D 缓存命中无需验证产物
# 32. Vitest workspace 在 monorepo 的测试配置，projects 划分、共享 setup 文件与跨包依赖的测试隔离如何组织？ A Vitest workspace 按包划分 projects，共享 setup 与测试工具包分发，跨包依赖默认真实链接、按需 mock 实现隔离 ✓ 正确答案 B monorepo 测试必须在根目录单文件配置 C 共享 setup 文件越多越好 D 跨包测试无法并行
# 33. Turborepo 的 --filter 在按包过滤执行的工程应用 A --filter 只能按包名精确匹配 B --filter 与 affected 完全相同 C --filter 支持包名、目录与依赖图方向选择器，用于单包开发与指定包 CI，与变更驱动的 affected 配合，发布前需全量兜底 ✓ 正确答案 D --filter 会扩大执行范围
# 34. Monorepo 的 lockfile 单一管理（pnpm-lock.yaml）的工程价值 A 每个包都应有独立 lockfile B 单一 lockfile 无法用于 CI C 根级单一 lockfile 保证全仓依赖一次解析、版本一致与变更集中，需禁止子 lockfile 并保持 package.json 与锁文件同步 ✓ 正确答案 D lockfile 冲突应手工合并
# 35. Monorepo 的 VS Code 工作区设置（.vscode/settings.json）的多根协作 A monorepo 只能打开单个包目录开发 B 编辑器设置与 CI 校验可以不同 C monorepo 无法用 VS Code 调试跨包代码 D 通过 .code-workspace 多根工作区与入库的 settings/extensions/tasks 统一编辑器体验，设置以根级共享、包级覆盖分层 ✓ 正确答案
# 36. Monorepo 的文档站（Docusaurus、VitePress） A 文档变更无需评审 B 文档应独立仓库维护 C 文档站作为 monorepo 包与代码同仓，内容手写与自动生成结合，版本化与发布联动，保证文档随代码演进 ✓ 正确答案 D 文档站无法与组件库联动
