TypeScript 测试体系升级：类型级回归与运行时验证双轨并进

先统一目标：双层测试策略要解决什么

很多团队把测试只理解成运行时断言，忽略了类型层也会发生回归：泛型推导变宽、公共类型破坏兼容、工具类型性能退化。结果是功能测试全部通过，但下游包编译失败。TypeScript 项目需要双层测试：类型层验证静态承诺，运行时层验证行为承诺，契约层验证边界承诺。三层缺一不可。

测试资产分层：每一层都要有阻断能力

建议把测试分成三类并分别设门禁阈值。类型测试关注公开 API 的推导结果与错误提示，可用 dtslint、tsd 或 expectType 风格断言。运行时测试关注业务逻辑、状态转移、异常处理，可用 Vitest/Jest + node:test。契约测试关注接口字段、状态码、事件结构与兼容策略，可从 OpenAPI/Zod 生成样本进行回归。CI 中应按风险分级：核心包类型回归失败直接阻断；外围包可进入人工审批。这样既保证质量，也控制研发反馈速度。

测试策略分层与门禁关系

flowchart LR
A[代码变更] --> B[类型测试]
A --> C[运行时单测]
A --> D[契约回归]
B --> E{类型兼容?}
C --> F{行为正确?}
D --> G{边界一致?}
E --> H[门禁汇总]
F --> H
G --> H
H --> I{是否允许发布}
I -- 否 --> J[阻断并生成回归报告]
I -- 是 --> K[进入发布流水线]

上图体现的核心原则是：契约与类型不是文档附属物，而是发布系统的硬门槛。每一个节点都要能产出可审计证据，例如差异报告、失败样本、影响范围清单。

关键实现片段：类型断言 + 运行断言并行

import { expectTypeOf, test, expect } from 'vitest';

type User = { id: string; name: string };

test('type-level contract', () => {
  expectTypeOf<User>().toMatchTypeOf<{ id: string }>();
});

test('runtime behavior', () => {
  const result = { ok: true, value: 42 };
  expect(result.ok).toBe(true);
});

代码片段强调一个现实问题：只有把类型推导与运行时校验绑定在同一模型上，团队才能避免“类型看起来没问题，线上却持续报错”的反复返工。

抽象热区图：只在高复用处使用高级类型

在双层测试策略场景中，类型系统的第一职责不是“炫技”，而是把团队共享语义固化为可审计资产。建议把类型分成三层：基础层（原子值与工具类型）、领域层（业务语义对象）、边界层（输入输出契约）。每一层都要定义 owner、发布节奏和兼容策略。特别是领域层，禁止把数据库字段命名直接暴露给上层业务，否则一旦存储结构变化，类型将成为反向耦合点。实践中可以通过“类型评审清单”控制质量：是否存在同义重复类型、是否出现 any 漏洞、是否有不可解释的条件类型嵌套、是否提供了最小可复现实例。

规模化阶段还需要治理类型债务。建议每周输出类型债务看板，指标至少包含：any 占比、类型断言占比、公共类型破坏兼容次数、类型检查耗时。看板不是为了追责，而是为了排优先级。对于高频变化模块，可采用“稳定接口 + 实验接口”双轨策略：稳定接口承诺兼容，实验接口允许快速试错并设置过期时间。这样可以在保证主干稳定的同时保留创新速度。

契约守门链：灰度与回滚都有判据

任何外部数据都是不可信输入。双层测试策略的高可用实践要求你在入口、出口、事件总线三个边界统一执行 schema 校验。入口校验保证请求体可解析，出口校验保证对外响应不漂移，事件校验保证异步链路可追溯。建议把校验失败分成“可恢复错误”和“不可恢复错误”两类：前者返回可读错误并上报指标，后者直接阻断并触发告警。

很多线上问题来自“类型看似正确但值语义错误”，比如金额字符串被当成数字、时区字段格式不一致、枚举值历史兼容被破坏。应对方法是把关键字段引入语义校验器，例如金额必须是最小货币单位整数、时间必须是 ISO 8601、枚举必须附带版本映射。这样做的收益是错误更早暴露，排障半径更小。

CI 时间预算：把分钟级回归变成秒级预警

构建优化必须先找关键路径。建议在本地与 CI 同时采集三个指标：TypeScript 检查耗时、打包耗时、测试耗时，并按包维度输出 Top N。针对耗时热点可采用四步法：第一步拆分项目引用，减少单次检查图规模；第二步启用增量与缓存，降低重复计算；第三步剔除无效输入，比如把文档、快照等不相关文件排除在构建图外；第四步按受影响范围运行任务，避免全量重复。

不要把 skipLibCheck 当万能按钮。它能短期提速，但会掩盖依赖类型问题。更稳妥的方式是对高质量依赖保持校验，对低质量历史依赖做分层白名单并设清理期限。若团队采用 monorepo，应把构建缓存命中率纳入发布门禁，低于阈值时自动输出失效原因报告，持续治理输入不稳定问题。

仓库规则引擎：lint + graph 组合约束

单仓治理强调“图优先”。目录结构只能表达归档方式，不能表达真实依赖。必须定期导出 project graph，检查循环依赖、跨层依赖、过高扇出节点。对高扇出包要谨慎改动，因为它们会放大构建成本和回归风险。建议为每个包声明责任域与依赖白名单，PR 阶段自动校验，不符合规则直接阻断。

发布策略建议采用“按图切片 + 按风险分级”。低风险叶子包可并行发布；核心基础包需要灰度和回归验证后再全量放开。每次发布后要回写依赖快照，确保问题复盘时能准确还原版本组合。治理的关键不在工具多少，而在规则是否可执行、可追踪、可复盘。

错误注入演练：验证降级与告警链路

测试不是单一维度。双层测试策略至少需要三类验证：类型层验证 API 推导与兼容，运行层验证业务行为与异常分支，契约层验证边界输入输出。类型层建议对公共类型与关键泛型做快照或断言，避免“重构不报错但语义变了”。运行层应覆盖正常路径、失败路径、边界路径，并在错误分支中验证日志字段是否完整。

契约层测试要和发布流程绑定。每次 schema 或 OpenAPI 变更都应自动生成回归样本，验证新版本对旧调用方是否兼容。对于不可兼容变更，必须附带迁移说明与灰度计划。测试结果应直接驱动发布决策，而不是仅作为报告存在。只有当测试成为门禁而非建议，质量收益才会稳定出现。

落地执行手册：把策略变成日常动作

为了让双层测试策略持续有效，建议按“周、迭代、季度”三层节奏运营。周节奏关注快反馈：处理新增类型债务、修复契约告警、检查构建预算偏移。迭代节奏关注中期目标：完成一批边界收敛、消化历史豁免、提升缓存命中率。季度节奏关注结构优化：重构高扇出模块、调整包边界、升级工具链版本。

组织协作上可采用 RACI 模型：平台组负责规则与基础设施，业务组负责具体改造与回归验证，测试组负责门禁质量与覆盖率审计。所有改动都应沉淀到可追溯产物：ADR、变更报告、回滚记录、事故复盘。建议把“未闭环事项”挂入下一迭代看板，避免治理动作半途而废。

风险控制建议使用四象限：高影响高概率问题优先自动化治理；高影响低概率问题通过演练与应急预案兜底；低影响高概率问题交给 lint/脚本自动修复；低影响低概率问题定期清理。只要每个问题都有明确归属和关闭条件，治理就不会停留在口号层面。

故障演练与回滚剧本

双层测试策略的发布前应至少准备三种演练：契约不兼容演练、构建性能退化演练、错误传播失控演练。契约演练模拟字段删除或语义变化，验证门禁能否准确阻断；性能演练模拟依赖扇出激增，观察是否触发预算告警；错误演练模拟下游超时与数据污染，验证降级路径和告警路径是否可用。

回滚剧本要写到可执行层面：谁有权限回滚、回滚到哪个版本、如何验证恢复、如何通知相关方。推荐把回滚验证自动化，至少覆盖核心健康检查、关键接口 smoke test、错误率指标恢复。回滚后必须做复盘，复盘关注“为何没在更早阶段发现”，而不是停留在“谁操作失误”。

如果团队规模较大，可建立“变更分级发布”机制：A级变更需要双人审批与灰度窗口，B级变更可自动发布但保留快速回滚，C级变更进入标准流水线。分级的目标是让流程与风险匹配，而不是增加审批负担。

先统一目标：双层测试策略 要解决什么