# 1. Prettier 3 的配置文件与 ESLint 的边界（格式化与代码质量） A Prettier 负责统一格式化，ESLint 负责代码质量，两者边界通过 eslint-config-prettier 关闭冲突的风格规则来协调 ✓ 正确答案 B ESLint 负责所有代码风格，Prettier 负责语法检查 C Prettier 可以完全替代 ESLint D ESLint 与 Prettier 对同一代码的修复总是兼容
# 2. Stylelint 在 CSS/SCSS/Less 代码规范与 Stylistic 规则的工程实践 A Stylelint 只能检查 CSS，不能处理 SCSS B Stylelint 通过 customSyntax 支持 SCSS/Less，规则分错误、可维护性与风格三类，风格规则与 Prettier 用 config-prettier 协调分工 ✓ 正确答案 C Stylelint 与 Prettier 必须同时启用全部规则 D Stylelint 不支持自动修复
# 3. ESLint 的自定义规则（RuleTester）在团队规范的工程应用 A 自定义规则无法自动修复 B RuleTester 只用于测试 Prettier 配置 C 自定义规则不需要 meta 声明 D 自定义规则通过 create 函数遍历 AST 报告问题，RuleTester 用 valid/invalid 用例验证规则与修复输出，团队规范可规则化发布为内部插件 ✓ 正确答案
# 4. ESLint no-unused-vars 与 TypeScript 的协作配置 A TS 项目应继续使用原生的 no-unused-vars B TS 项目应改用 @typescript-eslint/no-unused-vars 以理解类型语义，并与 tsc 的 noUnusedLocals 明确分工避免双轨差异 ✓ 正确答案 C TS 的未使用变量无法被检查 D type import 永远会被误报为未使用
# 5. Prettier 与 ESLint 的冲突解决（eslint-config-prettier） A eslint-config-prettier 关闭 ESLint 中与 Prettier 冲突的排版规则（置于 extends 最后），让 Prettier 独占格式化、ESLint 专注质量 ✓ 正确答案 B eslint-config-prettier 会把 ESLint 所有规则都关闭 C 冲突时以 ESLint 的修复为准 D eslint-config-prettier 只影响 React 项目
# 6. ESLint 的 autofix 在 CI 与保存时的工程策略 A 所有 ESLint 规则都支持自动修复 B CI 中应直接 --fix 后静默提交 C 开发期在保存时执行 --fix 即时消除可修复问题，CI 作为门禁校验不可修复问题，两者配合并治理豁免流程 ✓ 正确答案 D autofix 会破坏代码语义，只能手动修复
# 7. lint-staged 在大文件 lint 的性能取舍（增量 vs 全量） A lint-staged 只处理暂存变更文件，换取提交速度，但存在盲区，应用增量快筛与 CI 全量校验分层治理 ✓ 正确答案 B lint-staged 与 git 无关 C 增量 lint 能检查所有历史问题 D lint-staged 会 lint 全仓库所有文件
# 8. npm/pnpm/yarn/bun 在 lockfile、workspaces、Phantom dep 治理的取舍 A npm/yarn 传统模式存在幽灵依赖风险，pnpm 用严格符号链接布局与 workspace:* 协议治理，选型应综合 lockfile、workspaces 与依赖布局 ✓ 正确答案 B 所有包管理器的 lockfile 格式都相同 C pnpm 不支持 monorepo D 幽灵依赖只影响性能，不影响正确性
# 9. pnpm store 与 hard links 节省磁盘空间在大型 monorepo 的工程价值 A pnpm 每个项目都完整复制一份依赖 B hard links 在任何文件系统上都可用 C pnpm 用内容寻址 store 加硬链接实现全局去重，monorepo 与 CI 中显著节省磁盘与安装时间，但需注意跨盘失效与 store 清理 ✓ 正确答案 D pnpm store 无法被 CI 缓存
# 10. npm overrides/resolutions 与 yarn resolutions 在依赖冲突修复 A overrides 替换的版本必然与依赖兼容 B overrides 只能用于直接依赖 C overrides/resolutions 强制指定传递依赖版本，用于漏洞修复与冲突统一，但可能引入兼容性问题，应作为最后手段并附带原因与复审 ✓ 正确答案 D 使用 overrides 后无需再跑依赖审计
# 11. oxlint（Oxc）作为 ESLint 替代品在大型 monorepo 的工程取舍 A oxlint 覆盖 ESLint 全部规则 B oxlint 不支持任何 ESLint 配置 C oxlint 无法在 monorepo 中使用 D oxlint 以 Rust 性能做全量快速 lint，但规则覆盖与类型感知弱于 typescript-eslint，适合与 ESLint 分层并存 ✓ 正确答案
# 12. pnpm workspace 与 pnpm-workspace.yaml 在 Monorepo 的依赖提升与幽灵依赖治理 A pnpm 无法治理幽灵依赖 B pnpm 会把所有传递依赖提升到根 node_modules C workspace:* 协议会安装 registry 上的包 D pnpm-workspace.yaml 声明工作区包，严格符号链接布局根治幽灵依赖，公共工具链依赖用 hoist-pattern 白名单放行 ✓ 正确答案
# 13. npm 11 与 Yarn 4 Berry 的能力对比 A npm 11 与 Yarn 4 的安装模型完全相同 B npm 11 不支持 workspaces C Yarn 4 不支持 monorepo D Yarn 4 Berry 的 PnP 模型用运行时解析器替代 node_modules，确定性高且省磁盘，但部分工具需适配；npm 11 以 node_modules 兼容性见长 ✓ 正确答案
# 14. pnpm catalog 的依赖版本统一 在大型项目构建链的工程价值 A catalog: 协议会为每个包生成独立版本 B catalog 与 workspace:* 是同一机制 C 使用 catalog 后无需 lockfile D pnpm catalog 在根配置集中定义依赖版本，多包用 catalog: 引用，实现版本单点治理与全仓一致 ✓ 正确答案
# 15. npm/pnpm audit 在 CI 的门禁策略与误报处理，severity 阈值、白名单与例外审批流程 A 任何级别的漏洞都应阻塞 CI B audit 门禁按 severity 阈值阻塞并分层扫描，误报经可达性评估降级，白名单带到期时间并走审批流程 ✓ 正确答案 C audit 无法识别传递依赖漏洞 D 白名单可以永久生效
# 16. typescript-eslint 的 type-aware linting，parserOptions.projectService 相比 project 配置的工程优势，以及类型化规则（如 no-floating-promises）在捕获类型级问题的价值？ A 类型化规则只检查语法错误 B type-aware linting 用 TS 类型信息捕获 no-floating-promises 等语义问题，projectService 自动发现项目配置，比显式 project 清单更适合大型 monorepo ✓ 正确答案 C projectService 要求手工维护 tsconfig 列表 D 类型化规则无法检查 Promise 相关问题
# 17. Biome 2.x（Rust 实现）一体化 Lint+Format 替代 ESLint+Prettier 的工程价值 A Biome 覆盖 ESLint 全部插件规则 B Biome 2.x 一体化 Lint+Format 带来性能与配置收敛，但规则覆盖与插件生态弱于 ESLint，存量项目宜灰度迁移 ✓ 正确答案 C Biome 无法替代 Prettier 格式化 D Biome 只支持 JavaScript，不支持 TS
# 18. ESLint 9 Flat Config 配置的迁移与团队规范 A ESLint 9 Flat Config 用数组+对象模型替代 .eslintrc，extends 改为配置数组展开，团队规范可拆分为共享 flat 配置分片 ✓ 正确答案 B Flat Config 不支持 ignores C Flat Config 仍使用 extends 与 .eslintignore D 迁移只需改文件扩展名
# 19. Prettier 3 与格式化策略 A Prettier 3 以少配置多语言统一格式化，团队用保存时格式化、提交前兜底与 CI --check 三层策略收敛格式 ✓ 正确答案 B Prettier 配置项越多越好 C CI 中不应检查格式 D Prettier 支持的项目语言有限，仅 JS
# 20. oxlint（Rust linter）的极快速度与规则覆盖边界 A oxlint 覆盖所有类型感知规则 B oxlint 的速度来自 Rust 并行与无类型服务，但类型感知规则与自定义插件仍需 ESLint，适合作为快速层与 ESLint 并用 ✓ 正确答案 C oxlint 不支持 --fix D oxlint 是 JS 实现的 linter
# 21. Stylelint 与 Biome 对 CSS/SCSS/Less 文件格式化与 lint 的工程取舍 A Biome 的 CSS 规则深度与 Stylelint 完全一致 B Stylelint 以规则深度与 SCSS/Less 支持见长，Biome 以一体化与速度见长，存量样式库保留 Stylelint、新项目可选用 Biome 或混合 ✓ 正确答案 C Stylelint 不支持自定义语法 D Biome 无法格式化 CSS
# 22. ESLint 插件与 Prettier 的协作 A 推荐 Prettier 独立格式化、ESLint 专注质量并关闭冲突风格规则，eslint-plugin-prettier 模式单入口但有性能代价 ✓ 正确答案 B 插件风格规则应与 Prettier 同时生效互相覆盖 C eslint-plugin-prettier 是性能最优的协作方式 D ESLint 与 Prettier 无法在同一项目共存
# 23. Stylelint 16 与 CSS 规范治理 A Stylelint 16 默认不支持标准 CSS B Stylelint 无法检查设计令牌使用 C Stylelint 16 默认支持 CSS 并清晰了与 Prettier 的分工，工程上按错误、可维护性、命名与设计令牌分层治理，CI 门禁加增量启用 ✓ 正确答案 D Stylelint 16 已移除 --fix
# 24. ESLint 9（Flat Config）相较传统 .eslintrc 的工程配置取舍 A 迁移 Flat Config 无需任何验证 B Flat Config 与 .eslintrc 的继承模型相同 C Flat Config 不支持共享配置 D Flat Config 用数组顺序显式合并、无隐式继承，配置确定可审计，但存量配置迁移需改写 extends/overrides/ignore 结构 ✓ 正确答案
# 25. ESLint 的规则分层（base、recommended、strict） A 所有规则都应一次性全量开启 B 规则按 base/recommended/strict 分层表达风险与严格度，工程上用继承、按模块分级与 warn 到 error 渐进收紧 ✓ 正确答案 C 规则分层与团队无关 D recommended 配置一定包含全部规则
# 26. ESLint 的 React Hooks 规则（eslint-plugin-react-hooks）的现代价值 A Hooks 可以任意在条件中调用 B exhaustive-deps 与 React Compiler 无关 C 该插件只能在 React 18 中使用 D eslint-plugin-react-hooks 通过 rules-of-hooks 与 exhaustive-deps 前置拦截调用顺序与依赖完整性问题，是 React 开发的标准护栏 ✓ 正确答案
# 27. ESLint 的 a11y 规则（eslint-plugin-jsx-a11y）在无障碍工程的协作 A jsx-a11y 能检查所有运行时无障碍问题 B eslint-plugin-jsx-a11y 在源码层拦截静态可判定的无障碍问题，与 axe 测试、人工审计构成三层防线 ✓ 正确答案 C jsx-a11y 与键盘交互无关 D 无障碍只靠 lint 即可保证
# 28. ESLint 的 import 规则（eslint-plugin-import）在模块边界与重排的应用 A eslint-plugin-import 只能检查导入排序 B eslint-plugin-import 覆盖导入解析、架构边界（no-restricted-paths）、排序重排与幽灵依赖检查，支持 --fix 统一导入规范 ✓ 正确答案 C import/order 与 Prettier 必然冲突 D 该插件无法在 monorepo 中使用
# 29. ESLint 的安全规则（eslint-plugin-security）在 XSS 与注入检测的边界 A eslint-plugin-security 能完整检测所有 XSS 场景 B 使用该插件后应用必然安全 C eslint-plugin-security 拦截 eval、命令执行、危险正则等静态危险模式，但无法做数据流追踪，需与 SAST 与动态测试分层配合 ✓ 正确答案 D 该插件只检测性能问题
# 30. Prettier 的 printWidth 与 tabWidth 在团队统一的工程取舍 A printWidth 只影响注释换行 B 改 printWidth 不会产生大量 diff C 每个开发者可自定格式偏好 D printWidth 与 tabWidth 决定折行与缩进风格，一旦确立极少调整，团队统一并一次性格式化比频繁调参更优 ✓ 正确答案
# 31. Prettier 的 singleQuote 与 JSX 双引号的边界（jsxSingleQuote） A singleQuote 也控制 JSX 属性引号 B JSX 属性必须用单引号 C 引号配置与转义无关 D singleQuote 控制 JS 字符串、jsxSingleQuote 单独控制 JSX 属性引号，工程上按团队惯例组合配置并与 lint 对齐保持一致 ✓ 正确答案
# 32. Biome 2 的迁移（从 ESLint + Prettier） A biome migrate 无法处理 ignore 配置 B biome migrate 的规则映射完全等价于原 ESLint 配置 C 迁移后必须彻底删除 ESLint D Biome 迁移需盘点规则覆盖与语义差异，用双跑对比与逐模块灰度推进，保留回退能力 ✓ 正确答案
# 33. ESLint 的共享配置（eslint-config-*）在 Monorepo 的工程价值 A Monorepo 中每个包都应维护独立配置 B 共享配置不需要版本管理 C 共享配置无法与 flat config 协作 D 共享配置包实现规范单点维护与分层组合，Monorepo 中根级 base 加包级覆盖，并需治理覆盖碎片化 ✓ 正确答案
# 34. ESLint 的 --fix 在 CI 与本地编辑器集成的工程实践 A 编辑器保存时即时 --fix、CI 负责纯净校验（可修复未修复即失败），修复变更随提交可审阅并治理不可修复项 ✓ 正确答案 B 所有规则都可自动修复 C CI 中应直接 --fix 并静默提交修复 D --fix 会改变代码运行结果
# 35. dprint（Rust 实现的格式化工具）相较 Prettier 的工程性能取舍 A dprint 以 Rust 性能与更高可配置度见长，但与 Prettier 输出存在差异，迁移需一次性格式化并验证差异可接受 ✓ 正确答案 B dprint 不支持 TS 格式化 C dprint 比 Prettier 更慢 D dprint 的格式化输出与 Prettier 完全一致
# 36. Prettier 在 Markdown、JSON、YAML 多语言格式化的工程实践 A Prettier 支持 Markdown/JSON/YAML 等多语言格式化，工程上需用 overrides 差异化配置、ignore 排除生成文件并注意语义保护 ✓ 正确答案 B Prettier 只能格式化 JS/TS C 格式化 Markdown 会破坏所有换行语义 D JSON 格式化后无法被解析
# 37. ESLint 的缓存（--cache）在大项目 CI 的工程性能优化 A --cache 会永久缓存检查结果，配置变更也不失效 B 缓存文件应提交到 git 仓库 C --cache 会检查所有文件 D --cache 只检查变更文件并复用历史结果，配置与依赖变化会触发失效，CI 中应管理缓存目录并谨慎用于关键门禁 ✓ 正确答案
# 38. lint 的渐进式启用策略在遗留代码库的工程实践 A 遗留代码库应一次性全量开启所有 lint 规则 B 基线一旦建立就永久有效 C 渐进式启用先建立违规基线，门禁只拦截新增违规，再按规则、目录逐步治理存量债务并让豁免过期 ✓ 正确答案 D 渐进式启用只适用于新项目
# 39. Snyk/Dependabot/Renovate 在依赖自动升级的工程取舍 A 三者的功能完全相同 B 自动升级无需人工 review C Renovate 不支持私服 D Dependabot 内置安全更新、Renovate 高可配置版本升级、Snyk 专业安全扫描，常组合使用并配 CI 验证门禁 ✓ 正确答案
# 40. 依赖锁定文件 hash 与 lockfileVersion 在团队协作的可重复构建 A lockfile 只是为了加快安装速度，可以不入库 B lockfile 记录精确依赖树实现可重复构建，需入库、随 package.json 变更更新、统一格式版本并做完整性校验 ✓ 正确答案 C lockfile 冲突应手工逐行合并 D lockfileVersion 与可重复性无关
# 41. SemVer 语义化版本与依赖锁定（package-lock.json/pnpm-lock.yaml） A package.json 的 range 就是最终安装版本 B SemVer 的 range 声明表达可接受区间，lockfile 冻结实际解析版本，CI 用 frozen 安装保证可重复构建 ✓ 正确答案 C 依赖锁定后永远无需升级 D MAJOR 升级无需 review
# 42. Bun install 的性能与现代特性 A Bun install 与 npm 的安装行为完全一致 B Bun 不支持 monorepo workspaces C Bun install 以原生实现与全局缓存获得极快安装速度，但依赖解析与 node_modules 布局与 npm/pnpm 存在差异，需验证后切换 ✓ 正确答案 D Bun install 只能安装 Bun 专属依赖
# 43. pnpm workspace 在大型团队的可维护性 A pnpm workspace 可维护性只靠文档 B 各包可以自由依赖未声明的包 C workspace:* 发布时会保留协议原样 D pnpm workspace 通过结构约定、catalog/workspace 协议、changesets 与 CI 冻结校验等机制保证大型团队可维护性 ✓ 正确答案
# 44. corepack 与包管理器版本锁定，packageManager 字段与团队包管理器一致性保障 A packageManager 字段声明精确版本，corepack 按声明激活对应包管理器，配合 CI 联动保障团队与环境的版本一致 ✓ 正确答案 B packageManager 字段只是文档说明，不生效 C corepack 与 Node 版本无关 D 包管理器升级无需验证 lockfile
# 45. lockfile 完整性校验与投毒检测，lockfile 篡改检测与 CI 中的 lockfile 一致性门禁 A lockfile 以 integrity hash 校验下载内容、以 frozen-lockfile 门禁保证与 package.json 一致、以变更审查与审计扫描防投毒 ✓ 正确答案 B lockfile 的 integrity hash 用于格式化校验 C CI 安装时无需校验 lockfile 一致性 D lockfile 变更无需审查
# 46. pnpm 10 对依赖生命周期脚本（postinstall）的默认禁用，approve-builds/allowBuilds 与 ignoredBuiltDependencies 如何治理 install 脚本供应链风险？ A pnpm 10 默认允许所有依赖执行 postinstall B 生命周期脚本只会下载二进制，无安全风险 C 未批准的构建脚本会被静默跳过 D pnpm 10 默认禁用依赖生命周期脚本，用 approve-builds/onlyBuiltDependencies 白名单放行、ignoredBuiltDependencies 显式忽略，配置入库保证 CI 一致 ✓ 正确答案
# 47. Prettier 的 .prettierignore 与 .gitignore 的协作边界 A Prettier 总是格式化所有文件 B .prettierignore 不存在时 Prettier 不格式化任何文件 C .prettierignore 可以取代 .gitignore D Prettier 默认跟随 .gitignore 且 .prettierignore 优先级更高，用于豁免"入库但不格式化"的生成文件等场景 ✓ 正确答案
# 48. ESLint 的规则自定义（@typescript-eslint/no-explicit-any 等级）的工程取舍 A any 只在书写处影响类型 B no-explicit-any 默认 error 并联动 no-unsafe-* 拦截类型逃逸，特殊场景用带理由的局部豁免与分目录等级治理 ✓ 正确答案 C any 的使用对类型安全无影响 D 规则等级一旦设定不可调整
# 49. OSV-Scanner / Snyk / Trivy 在 CI 供应链安全扫描的工程取舍 A 三者功能完全相同 B 安全扫描工具不需要门禁策略 C Trivy 只能扫描 npm 依赖 D OSV-Scanner 免费开源扫依赖漏洞、Trivy 覆盖容器与镜像、Snyk 平台化治理，按范围与成本分层组合进 CI ✓ 正确答案
# 50. npx 与 bunx 在跨包运行 CLI 与生态隔离的工程价值 A npx 只能运行已全局安装的命令 B npx 与 bunx 完全等价 C npx/bunx 临时拉取并运行 CLI，支持按命令固定版本与免全局安装，实现版本隔离，但需注意临时拉取的供应链风险 ✓ 正确答案 D npx 会污染项目依赖
# 51. Provenance 与 Sigstore 在 npm 包的供应链签名验证 A Provenance 证明包代码没有漏洞 B Sigstore 需要发布方自管长期密钥 C Provenance 只能在本地发布时生成 D npm Provenance 用 OIDC 身份与 Sigstore 签名生成来源证明，消费方可用 npm audit signatures 验证包来源与构建环境 ✓ 正确答案
# 52. SBOM（软件物料清单）与供应链可追溯 A SBOM 只包含代码不包含依赖 B SBOM 与 lockfile 是同一事物 C SBOM 以 SPDX/CycloneDX 标准列出组件、许可与漏洞引用，支撑漏洞管理、合规审计与影响面分析，需随发布持续更新 ✓ 正确答案 D SBOM 生成一次即可永久使用
