# 1. isolatedModules、verbatimModuleSyntax（TS 5.0+）对打包器（Babel/esbuild/SWC/Oxc）的协作 A isolatedModules 要求每个文件可独立转译（禁 const enum 等），verbatimModuleSyntax 强制保留 import type/export type 修饰符，保证与打包器语义一致 ✓ 正确答案 B esbuild 可以跨文件做类型分析 C verbatimModuleSyntax 会自动合并类型导入 D Babel 不需要 isolatedModules 配合
# 2. skipLibCheck 的开启代价（第三方类型 bug 隐藏）与治理 A skipLibCheck 会检查所有 .d.ts 文件 B skipLibCheck 跳过第三方 .d.ts 检查以提速，但会隐藏声明冲突与类型 bug，需用模块增强修正并锁定依赖版本治理 ✓ 正确答案 C skipLibCheck 与声明冲突无关 D 开启 skipLibCheck 后 tsc 不做任何检查
# 3. erasableSyntaxOnly（TS 5.8+）禁止 enum/namespace/参数属性的纯转译器兼容性 A erasableSyntaxOnly 允许使用 enum B erasableSyntaxOnly 只允许擦除后零运行时语义的语法，禁止 enum/namespace/参数属性等需生成代码的语法，保证纯转译器兼容 ✓ 正确答案 C 接口类型在 erasableSyntaxOnly 下被禁止 D 参数属性是纯类型语法
# 4. @ts-ignore/@ts-expect-error/@ts-nocheck 的滥用治理 A 三个指令语义完全相同 B @ts-ignore 在错误修复后会自动报错提醒 C @ts-nocheck 只抑制一行 D @ts-expect-error 在下一行无错误时会报"未使用"错误 ✓ 正确答案
# 5. lib 配置 在 IDE 智能提示与重构的工程价值 A lib 决定可用的标准库类型集合（ES/DOM/WebWorker 等），与 target 解耦，直接影响 IDE 补全与 API 可用性检查 ✓ 正确答案 B lib 与 target 必须一致 C lib 配置只影响产物大小 D DOM 类型不需要 lib 配置
# 6. @deprecated JSDoc 在库发布与消费的类型一致性 A @deprecated 只影响文档生成 B @deprecated 由 TS 识别并在 IDE/检查中提示废弃与替代方案，是库版本演进中"类型与迁移信息一致"的载体 ✓ 正确答案 C 废弃 API 应该直接删除类型 D IDE 无法显示废弃提示
# 7. TypeScript 模块解析策略（classic、node16、nodenext、bundler） A bundler 模式要求导入必须带扩展名 B node16/nodenext 按文件与 package.json 区分 ESM/CJS 并尊重 exports，bundler 模式模拟打包器解析（无扩展名、条件导出），按运行环境选型 ✓ 正确答案 C classic 模式是现代推荐解析策略 D node16 与 node10 解析规则相同
# 8. .d.ts 声明文件在第三方库类型扩展（declare module）的工程应用 A declare module 可为无类型库补声明，也可对已有模块做增量增强，配合 declare global 扩展全局类型 ✓ 正确答案 B declare module 只能声明新模块，不能增强已有模块 C 模块增强只能出现在脚本文件中 D declare module 支持运行时实现
# 9. tsconfig.json 的 strict 系列选项在大型项目的渐进启用策略 A strict 只包含 strictNullChecks B 开启 strict 后不再需要 lint C strictNullChecks 无法迁移到存量代码 D strict 是一族检查选项的聚合，大型项目应通过配置继承、目录分区与分批修复渐进启用 ✓ 正确答案
# 10. moduleResolution: bundler 在 Vite、Webpack 等打包器下的类型解析行为 A bundler 模式不支持无扩展名导入 B moduleResolution: bundler 模拟打包器解析（无扩展名、exports 条件），需与 resolve.alias/conditionNames 配置同步保证类型与运行时一致 ✓ 正确答案 C bundler 模式忽略 package.json exports D Vite 工程不应使用 bundler 模式
# 11. exports/imports 条件导出（含 import/require/types/browser） A exports 字段只有 import 一种条件 B exports 条件按声明顺序匹配，types 条件应前置保证类型优先 ✓ 正确答案 C 子路径不需要在 exports 中声明 D exports 与 main 同时使用时 main 优先
# 12. 类型声明合并（declaration merging）在全局扩展与库作者的应用 A 同名 interface 会互相覆盖 B namespace 与 class 无法合并 C 声明合并使同名 interface/namespace 自动合并，可用于全局类型扩展与库插件接口设计 ✓ 正确答案 D declare global 只能用于类型别名
# 13. 环境声明（ambient declarations） A 环境声明用 declare 描述运行时已存在的全局/模块内容（无类型包、CSS 导入、全局变量），只提供类型不产生实现 ✓ 正确答案 B ambient 声明会生成运行时代码 C declare module 不能用于 CSS 文件 D ambient 文件默认是模块
# 14. TypeScript 5.x 实验装饰器（@dec）与 Stage 3 标准装饰器的转译器差异 A legacy 装饰器与 Stage 3 装饰器可以混用 B legacy 装饰器是 (target, key, descriptor) 形态，Stage 3 装饰器是 (value, context) 形态且支持 Symbol.metadata，二者语义不同需按模式配置转译器 ✓ 正确答案 C Stage 3 装饰器需要 experimentalDecorators D 两套装饰器转译结果完全相同
# 15. ECMAScript 装饰器（Stage 3，access/context 二元形态） A Stage 3 装饰器接收 (target, key, descriptor) 三参数 B context 没有静态信息 C 字段无法被装饰 D Stage 3 装饰器是 (value, context) 形态，context 提供 kind/name/addInitializer/metadata 等能力，TS 5.0+ 原生支持 ✓ 正确答案
# 16. 装饰器在类、方法、访问器、字段的元数据应用 A 装饰器只能用于类 B 字段装饰器无法记录元数据 C 装饰器可在类/方法/访问器/字段上附加元数据并改写行为，是 DI、ORM、校验等框架的声明式元数据基础 ✓ 正确答案 D 装饰器在运行时求值顺序无关紧要
# 17. auto-accessor（随装饰器 Stage 3） A accessor 关键字需要手写 get/set B accessor 与装饰器无关 C auto-accessor 不支持私有字段 D accessor 自动生成后备字段与 get/set，装饰器应用于访问器而非字段，可通过 context.access 读写值 ✓ 正确答案
# 18. 装饰器在 Angular、Lit、Aurelia 的核心地位与设计哲学差异 A Angular 以装饰器为核心契约，Lit 用装饰器声明响应式属性，Aurelia 主张装饰器可选，三者的设计哲学不同 ✓ 正确答案 B 三个框架对装饰器的依赖程度相同 C Aurelia 强制使用装饰器 D Lit 不使用 TypeScript
# 19. Stage 3 装饰器元数据（context.metadata 与 Symbol.metadata）的工程应用 A 装饰器通过 context.metadata 写入类共享元数据，可用 Symbol.metadata 读取，是 DI/校验/ORM 等元数据驱动设计的标准通道 ✓ 正确答案 B context.metadata 在每个装饰器间相互独立 C Symbol.metadata 是运行时全局对象 D 元数据无法跨继承链合并
# 20. module: Node16/NodeNext 与 moduleResolution: bundler 在 ESM/CJS 互操作的工程取舍 A bundler 模式会检查 ESM/CJS 互操作限制 B nodenext 下 ESM 可以静态 import 任何 CJS 包 C node16/nodenext 严格模拟 Node 的 ESM/CJS 互操作规则，bundler 模式假设打包器统一处理互操作，按运行环境取舍配置 ✓ 正确答案 D bundler 模式可用于纯 Node 库发布
# 21. exactOptionalPropertyTypes 在 API 边界严格区分 T | undefined 与 T? 的语义差异 A 开启 exactOptionalPropertyTypes 后 T? 仍可显式赋 undefined B T? 与 T | undefined 在任何模式下都等价 C 该选项只影响接口继承 D exactOptionalPropertyTypes 使可选属性只接受"缺失"，显式 undefined 需声明为 T | undefined，从而在 API 边界严格区分两种语义 ✓ 正确答案
# 22. 声明文件（.d.ts）与双格式包发布的消费者兼容 A 双格式包只需一份 .d.ts B 双格式包应按 ESM/CJS 分别分发 .d.mts/.d.cts 声明，exports 中 types 条件与 import/require 配对且前置，保证两类消费者类型一致 ✓ 正确答案 C node16 解析会忽略 .d.mts D types 条件应放在条件列表最后
# 23. TypeScript 项目引用（Project References） A 项目引用不需要 composite B Project References 通过 references + composite + tsc --build 按依赖图增量构建，适合 Monorepo 分层拆分与缓存 ✓ 正确答案 C tsc --build 会全量重编译所有项目 D 项目引用支持循环引用
# 24. tsconfig.json 的 target、module、moduleResolution、strict 核心配置影响 A target 决定模块解析规则 B target 决定语法转译级别、module/moduleResolution 决定模块语义、strict 决定检查严格度，三者按场景组合配置 ✓ 正确答案 C moduleResolution 与 module 无关 D strict 只包含 noImplicitAny
# 25. allowImportingTsExtensions（TS 5.0+）与 --rewriteRelativeImportExtensions 的边界 A allowImportingTsExtensions 要求 noEmit 或 emitDeclarationOnly，rewriteRelativeImportExtensions 在 emit 时把相对导入的 .ts 改写为 .js，适合原生 ESM 项目 ✓ 正确答案 B allowImportingTsExtensions 允许带 .ts 后缀导入且可同时 emit C rewrite 会改写裸包名导入 D 打包器项目必须开启 rewrite
# 26. useDefineForClassFields 与 target ES2022+ 在 class field 语义的协作 A target ES2022+ 时 useDefineForClassFields 默认使用 [[Set]] 赋值语义 B target ES2022+ 时 useDefineForClassFields 默认开启 [[Define]] 语义，影响继承 setter 触发与字段遮蔽，升级 target 需回归相关场景 ✓ 正确答案 C class field 语义与装饰器无关 D useDefineForClassFields 只影响枚举顺序
# 27. isolatedDeclarations（TS 5.5+）的显式返回类型约束与 .d.ts 生成加速 A isolatedDeclarations 允许隐式推断的导出函数 B isolatedDeclarations 会加快运行时执行 C isolatedDeclarations 要求导出函数显式标注返回类型以便逐文件独立生成 .d.ts，加速库与 Monorepo 的声明产出 ✓ 正确答案 D 该选项与声明生成无关
# 28. 命名空间（namespace）与 ES Module 在工程化代码组织的取舍 A namespace 支持 tree-shaking B ES Module 静态可分析、支持 tree-shaking 是现代代码组织标准，namespace 主要保留在声明文件与全局类型组织场景 ✓ 正确答案 C ES Module 无法处理循环依赖 D namespace 与 ES Module 完全等价
# 29. TypeScript 的 declare 与 ambient 上下文在大型 monorepo 的工程价值 A ambient 文件之间互不可见 B declare global 只能在 .d.ts 中 C monorepo 中集中组织 ambient 声明（全局类型、模块增强、资源声明）可统一全局类型面，减少各包重复声明与冲突 ✓ 正确答案 D 环境声明文件可以有 import/export
# 30. @ts-check 在 JSDoc 注释启用类型检查的渐进迁移策略 A @ts-check 只在 TS 文件生效 B @ts-check 在 JS 文件启用类型检查，配合 JSDoc 类型注释可实现"JS 加类型 → 逐步迁移 .ts"的渐进策略 ✓ 正确答案 C JSDoc 无法定义泛型 D checkJs 与 @ts-check 互斥
# 31. TypeScript 配置文件继承（extends）在多项目共享配置的工程实践 A extends 浅合并 compilerOptions，files/include 不继承，paths 按各自文件解析，多项目共享配置宜用 base + 覆盖模式 ✓ 正确答案 B extends 会继承子配置的 files 字段 C extends 深度合并所有字段 D 子配置无法覆盖父配置的 strict
# 32. emitDeclarationOnly 与 declaration 在类库发布的工程取舍 A 类库发布常用打包器产 JS + tsc --emitDeclarationOnly 产 .d.ts 的分工，需保证转译语义一致并单独做类型检查 ✓ 正确答案 B emitDeclarationOnly 会同时输出 JS 与声明 C emitDeclarationOnly 会执行类型检查 D declarationMap 无法用于类库
# 33. JSDoc @typedef 与 @template 在无 TypeScript 项目的轻量类型化 A @typedef 定义命名类型、@template 定义泛型，配合 @ts-check 可在纯 JS 项目获得类型检查与补全，但能力弱于 .ts ✓ 正确答案 B @template 可以定义运行时泛型 C JSDoc 类型化与 IDE 补全无关 D @typedef 只能定义基本类型
# 34. import type 与 export type 在构建产物与 tree-shaking 的工程取舍 A import type 会触发模块执行副作用 B import type/export type 声明纯类型导入，擦除后零产物，配合 verbatimModuleSyntax 显式化可提升摇树精度与可读性 ✓ 正确答案 C 类型导入与摇树无关 D import type 只能用于 .d.ts
# 35. Monorepo 中共享类型包（types package） A 类型包应该包含运行时实现 B Monorepo 共享类型包按域拆分导出、用声明构建快速产出，配合项目引用消费，并需管控 API 演进与版本 ✓ 正确答案 C 类型包无法被项目引用消费 D 类型包不需要版本管理
# 36. TypeScript package.json 的 exports 字段在子路径导出的类型解析 A exports 未声明的子路径仍可被类型解析 B exports 不影响子路径的类型解析 C exports 子路径通过键与通配符声明，每个入口需配对 types 条件且置于条件首位，未声明路径类型与运行时都不可解析 ✓ 正确答案 D 通配符子路径不需要 types 条件
# 37. tsc --build 与 Project References 增量构建在大型代码库的应用 A tsc --build 基于项目引用依赖图增量重建，利用 .tsbuildinfo 缓存，CI 与本地统一命令并定期 --force 校验缓存 ✓ 正确答案 B tsc --build 总是全量重建 C 项目引用不支持 --watch D 增量缓存永远不会失效
# 38. ts-node、tsx 与 SWC 在 Node.js 运行时类型执行的工程取舍 A ts-node 默认会做类型检查 B SWC 转译语义与 tsc 完全一致 C tsx 支持类型检查 D ts-node/tsx/SWC 是开发期 TS 执行方案，tsx 基于 esbuild 启动快，生产应编译为 JS，CI 用 tsc --noEmit 独立把关类型 ✓ 正确答案
# 39. 声明文件生成（dts-bundle-generator、rollup-plugin-dts）在类库发布的取舍 A dts-bundle-generator/rollup-plugin-dts 把声明打包为单文件，可内联/外置类型，发布后需用类型测试校验声明失真 ✓ 正确答案 B rollup-plugin-dts 会执行类型检查 C tsc 原生声明不支持子路径 D 声明打包与双格式发布无关
# 40. verbatimModuleSyntax（TS 5.0+）与 importsNotUsedAsValues 在强制 type 导入与打包器 tree-shaking 的现代取舍 A verbatimModuleSyntax 取代 importsNotUsedAsValues，强制类型导入显式 type 化并原样输出，配合 isolatedModules 提升摇树精度与转译器一致性 ✓ 正确答案 B importsNotUsedAsValues 是 TS 5.0 新特性 C verbatimModuleSyntax 会自动删除类型导入 D 该选项只影响 .d.ts 生成
# 41. .d.ts 与 .d.mts/.d.cts 在 ESM-only/CJS-only 包的声明分发的现代工程实践 A ESM 包可以用 .d.cts 声明 B .d.mts 与 .d.ts 完全等价 C 声明格式需与产物模块格式匹配（ESM 用 .d.mts、CJS 用 .d.cts），单格式包保持单一声明，双格式包才需双声明分发 ✓ 正确答案 D 声明格式不影响互操作类型
# 42. paths 与 baseUrl 在 TS 路径别名与 Vite/Rspack resolve.alias 的协作关系 A paths 别名会自动改写产物路径 B tsconfig paths 管类型解析、打包器 resolve.alias 管运行时替换，二者需保持一致，可用 vite-tsconfig-paths 等单一来源维护 ✓ 正确答案 C Vite 无法读取 tsconfig paths D paths 与 baseUrl 无关
# 43. Reflect Metadata 在依赖注入与 ORM 映射的应用 A emitDecoratorMetadata 生成运行时类型检查代码 B Reflect Metadata + emitDecoratorMetadata 记录设计时类型元数据，DI 容器读取 paramtypes 注入、ORM 读取属性元数据映射，现代方案转向 Symbol.metadata ✓ 正确答案 C Reflect Metadata 与装饰器无关 D ORM 不需要元数据即可映射
# 44. 装饰器在 Nest.js、TypeORM、tsoa 等框架的元数据驱动设计 A tsoa 在运行时读取装饰器元数据 B Nest.js 运行时用元数据构建 DI/路由、TypeORM 读取实体元数据映射、tsoa 构建期生成 OpenAPI，装饰器元数据驱动方式各有不同 ✓ 正确答案 C 三个框架都使用代码生成 D 装饰器与框架无关
# 45. TypeScript Roadmap（持续演进） A TypeScript 每年只发布一个大版本 B 新特性无需评估即可引入 C tsgo 已经正式取代 tsc D TypeScript 约 3 个月一个 minor，方向由 GitHub/迭代计划驱动，近期聚焦 tsgo 原生编译器与装饰器，升级前应评估 breaking changes 并用 CI 灰度 ✓ 正确答案
# 46. TS 5.5/5.7/5.8 的新特性（--rewriteRelativeImportExtensions、--noUncheckedSideEffectImports、条件分支收窄、类型谓词推断）对工程体验的改善 A 类型谓词推断让 filter 后的数组元素自动收窄 B TS 5.5-5.8 的新特性分别改善推断（谓词/分支收窄）、模块处理（rewrite 扩展名、副作用导入检查）与构建约束（erasableSyntaxOnly） ✓ 正确答案 C noUncheckedSideEffectImports 用于检查类型导入 D rewriteRelativeImportExtensions 在运行时改写路径
# 47. using/await using 声明（TS 5.2+ / Stage 3 提案 Explicit Resource Management） A using 只是 try/finally 的语法糖，不调用任何协议 B using 声明在作用域结束时自动调用资源的 Symbol.dispose 方法 ✓ 正确答案 C await using 用于同步释放 D 资源管理只能手动 release
# 48. TypeScript 项目使用 native decorators 与 useDefineForClassFields 的取舍 A Stage 3 装饰器与 useDefineForClassFields: true 的 define 语义天然对齐，新项目应统一 ES2022+ 配置，避免混用 legacy 装饰器 ✓ 正确答案 B native decorators 与 useDefineForClassFields 无关 C legacy 装饰器与 native 装饰器可以混用 D accessor 关键字与装饰器冲突
# 49. TC39 装饰器提案时间线与 Babel/SWC 转换兼容性 A 装饰器提案已经 Stage 4 定稿 B Babel 所有版本装饰器语义相同 C 装饰器提案从旧 descriptor 形态演进为 Stage 3 的 (value, context) 形态，Babel/SWC 按 legacy/2023-05/2023-11 版本选择语义，必须与源码语义对齐 ✓ 正确答案 D SWC 不支持装饰器
# 50. 装饰器与 Class Field 的执行顺序（类 > 字段 > 方法） A 类装饰器最先执行 B 装饰器执行顺序与声明顺序无关 C 成员装饰器先于类装饰器执行（类可能被替换），字段初始化发生在实例化期，理解时序是元数据框架调试的关键 ✓ 正确答案 D addInitializer 在装饰器执行前调用
# 51. 升级 TypeScript 大版本前用 --explainFiles 与 CI 类型差异评估破坏性变化 A 升级不需要基线对比 B 升级前用 --explainFiles 核对文件集合、CI 双版本矩阵对比错误面，并按 breaking changes 分类渐进修复 C --explainFiles 用于解释每个文件被包含与解析的原因 ✓ 正确答案 D --explainFiles 会修改 tsconfig
# 52. TypeScript 5.0+ 装饰器 在类型测试（tsd、expectTypeOf） A 装饰器不影响类型的测试 B 装饰器改写类型后，需用 tsd/expectTypeOf 对装饰后签名、工厂泛型与元数据做断言，并与运行时测试双覆盖 ✓ 正确答案 C tsd 无法测试装饰器 D @ts-expect-error 不能用于装饰器场景
# 53. TS 的 module: "preserve"（5.4+）在原样输出 import 语句与 Bundler 解析的工程价值 A module: preserve 会把 import 转成 require B module: preserve 原样输出 import/export，配合 moduleResolution: bundler 把模块转换完全交给打包器，适合打包器工程 ✓ 正确答案 C preserve 与 bundler 解析冲突 D preserve 适合 Node 直接运行场景
# 54. declaration: true 与 declarationMap（source map for d.ts）在 IDE 跳转与库用户体验的现代取舍 A map 文件不影响发布物 B declarationMap 提供声明到源码的映射，改善消费端调试体验，但增加包体积且闭源场景需权衡 C declaration 不需要 declarationMap 即可跳转源码 D declarationMap 让 IDE 从声明跳转到源码 ✓ 正确答案
# 55. globalAugmentations 与 declare global 在扩展第三方库类型（如 Express、Vue）的边界 A declare global 只能在脚本文件中使用 B window 扩展只能用 declare module C 库用 type 定义时也可以被自动合并 D declare global 在模块文件中扩展全局（如 Express.Request），第三方库的类接口用模块增强扩展，均依赖接口合并机制且需纳入类型入口 ✓ 正确答案
# 56. TS 5.x 的 noUncheckedSideEffectImports（5.6+）在 CSS、SVG 等副作用导入的检测能力 A 该选项忽略所有副作用导入 B noUncheckedSideEffectImports 检查无绑定副作用导入的路径与声明 ✓ 正确答案 C 开启后 CSS 导入必然报错 D 副作用导入不需要任何类型声明
# 57. tsconfig.json 的 include/exclude/files 三者优先级与大型 Monorepo 的工程实践 A exclude 可以排除 files 中显式列出的文件 B 未配置 include 时不包含任何文件 C include 的 glob 相对项目根目录 D 生效文件集合 = (files ∪ include) - exclude，exclude 只作用于 include 结果，Monorepo 应限定 include 范围并用 references 组织 ✓ 正确答案
# 58. allowImportingTsExtensions（TS 5.0+）在搭配 bundler 时的 "noEmit": true 工程边界 A allowImportingTsExtensions 可以搭配 tsc emit 使用 B 打包器无法解析 .ts 后缀 C allowImportingTsExtensions 要求 noEmit 或 emitDeclarationOnly，源码级 .ts 后缀导入由打包器解析，需要 tsc 产物时应改用 rewrite 方案 ✓ 正确答案 D 该选项与声明生成无关
# 59. package.json 的 types/typings/exports.types 字段在类型入口分发与 ESLint 解析的工程价值 A exports.types 的优先级低于 types 字段 B ESLint 不依赖类型入口 C types 字段只影响 IDE 补全 D exports.types 条件按分支分发类型入口，优先级高于 types，缺失时 TS 回退且 ESLint 类型感知规则失效，发布前应校验 ✓ 正确答案
