TypeScript 类型推断变化如何安排升级回归

TypeScript 升级后出现的新报错，不能一看到红线就回滚，也不能把所有问题都归因于业务代码。更稳妥的顺序是：先锁定旧版本和配置做基线，再把差异分成类型推断、声明文件、依赖类型和运行时行为四类，最后用最小复现决定是补注解、修 API 还是延后升级。

官方地址：https://www.typescriptlang.org/

先把类型变化拆成四类可观察差异

TypeScript 的推断不是单一开关。数组和对象会经过 best common type，函数参数还会受到 contextual typing 影响；一个泛型调用的输入、返回值和上下文都可能参与推断。因此升级后要先建立一份“小而稳定”的基线：记录 typescript、@types/*、tsconfig.json、构建命令和声明输出。

用双版本检查和最小复现安排升级门禁

不要直接在主分支覆盖升级。复制一份锁文件，让旧编译器和候选编译器对同一份源码分别执行类型检查、声明生成和测试。出现差异后，再把报错缩到一个泛型函数或一个对象字面量，记录“旧版本推断类型—新版本推断类型—期望类型”三列。

// 让 colors 成为唯一推断来源，避免 defaultColor 反向扩大 C。
function createPalette(colors: C[], defaultColor: NoInfer) {
  // 业务实现不在这里改变；注解只固定 API 的推断边界。
  return { colors, defaultColor };
}

// 这里应当暴露参数不兼容，而不是把 "blue" 并入 C。
createPalette(["red", "green"], "blue");

上例的重点不是把项目全部改成显式类型，而是验证“哪个参数应该提供证据”。如果新版本只改变了推断路径，可以在公共 API 边界补一个类型参数；如果只是内部局部变量，优先补局部注解，不要扩大改动面。

5.9 与 6.0 的差异怎样落到检查清单

TypeScript 5.9 的发布说明指出，修复类型变量泄漏可能改变类型，必要时可给泛型调用补充显式类型参数。6.0 又改变了无实际 this 使用函数的上下文敏感判断，并提供 --stableTypeOrdering 帮助比较 6.0 与 7.0 的迁移差异。这个标志是诊断工具，不适合无期限打开；官方还提醒它可能明显增加检查耗时。

1. 先比较公开包的 .d.ts，把类型顺序变化和签名变化分开。
2. 再执行关键泛型 API 的最小复现，确认错误是变严格、变宽松还是仅显示顺序变化。
3. 对确实依赖推断的调用补最小注解，然后重新跑声明检查和运行时契约测试。
4. 最后在一小部分包或流水线任务灰度，观察构建时长、错误数量和下游类型反馈。

相关问题

升级后只多了类型错误，是否说明 TypeScript 版本不能用？

不一定。先确认错误来自推断、lib.d.ts 还是 @types/*，再用最小复现判断是暴露了潜在问题还是不必要的破坏。

什么时候应该直接写显式类型？

当调用边界是公共 API、推断结果会进入声明文件，或多个参数同时参与推断时，显式类型能固定契约；普通局部变量不必为了消除每条提示都加注解。

--stableTypeOrdering 要长期保留吗？

不建议。它适合诊断 6.0 到 7.0 的差异；定位完成后，应修复真正依赖隐含推断或声明顺序的代码。