TypeScript 运行时契约治理：Schema 生命周期与发布门禁设计

先统一目标：运行时 Schema 治理要解决什么

“有类型就安全”是最危险的错觉。TypeScript 只在编译阶段生效，线上仍会收到未知输入、历史版本数据和第三方脏数据。运行时 schema 的职责就是把不确定性挡在边界外，并且让失败可观察、可追责、可回滚。真正可持续的 schema 治理，不是写几段校验代码，而是建立生命周期：设计、评审、发布、监控、淘汰。

Schema 生命周期管理：设计到淘汰一条线

建议每个 schema 都带版本号和状态（draft、active、deprecated、sunset），并且强制在 PR 中提供“兼容性说明”。新增字段默认可选，移除字段必须走双读双写窗口。发布前执行三类校验：静态兼容检查、样本回放检查、契约回归测试。发布后关注两类指标：schema 校验失败率、字段缺失/溢出分布。只要失败率异常，就自动触发灰度回滚或限流。这样做的结果是：运行时契约不再是事故后补丁，而是发布前提条件。

Schema 治理生命周期

flowchart TD
A[Schema 设计] --> B[评审与版本标记]
B --> C[代码生成与类型同步]
C --> D[发布前兼容检查]
D --> E[灰度发布]
E --> F[线上校验指标监控]
F --> G{失败率异常?}
G -- 是 --> H[自动回滚/降级]
G -- 否 --> I[进入稳定期]
I --> J[废弃与淘汰流程]

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

关键实现片段：版本化 schema 注册表

import { z } from 'zod';

type SchemaStatus = 'draft' | 'active' | 'deprecated' | 'sunset';

const registry = new Map<string, { status: SchemaStatus; schema: z.ZodTypeAny }>();

export function registerSchema(key: string, status: SchemaStatus, schema: z.ZodTypeAny) {
  registry.set(key, { status, schema });
}

export function validateByKey(key: string, input: unknown) {
  const entry = registry.get(key);
  if (!entry) throw new Error('SCHEMA_NOT_FOUND');
  return entry.schema.parse(input);
}

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

类型平台化：从个人技巧升级为团队能力

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

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

边界可信化：将未知值收敛到受控域

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

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

构建分层术：声明产物与运行产物分离

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

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

跨包契约协同：类型、schema、文档同源

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

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

性质测试补位：用数据生成覆盖隐藏路径

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

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

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

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

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

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

故障演练与回滚剧本

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

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

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

先统一目标：运行时 Schema 治理 要解决什么