TypeScript 改了 lib 或 target，增量检查仍沿用旧结果

把 lib 从较低标准改回 ESNext，toSorted() 仍报 TS2550；反过来收紧库范围，增量检查又可能继续通过。若不使用旧构建信息的检查能得到正确结果，应检查配置变化是否让增量诊断失效。

这一具体问题出现在 TypeScript 7.0.2，5.9.3 与 6.0.3 的相同对照正常。7.1.0-dev.20260930.4 虽不再出现同样的旧错误，仍存在漏报，不能把该开发快照当成完整修复。当前正式 7.0.2 的项目应按下面的配置对照确认，而不是只看一次退出码。

同一份源码，库集合已经变了

触发结构很小：

export const sorted = [3, 1, 2].toSorted();

它需要 ES2023 或更新的相应标准库声明。先用允许该 API 的配置检查，再加入 lib: ["ES2020"]；若没有显式 lib，调整 target 也会影响默认库选择。收紧后应出现相应类型错误，恢复后应清除。

受影响的增量状态可能把旧错误保留下来，也可能把“没有错误”保留下来。后者更容易漏过 CI：没有诊断不代表编译器真的按新库集合重新检查过。标准库声明允许调用，也不会为运行环境安装 toSorted 的实现，类型检查与运行时兼容仍需分开。

冷检查必须使用同一份配置

保存编译器准确版本、配置和原构建信息，核对工作目录与实际调用的可执行文件。对普通非 composite 项目，可在隔离的诊断配置中关闭 incremental，用相同源码、lib、target 和其他检查选项作一次不复用旧状态的对照。

项目引用和 composite 有独立约束，不要把 --incremental false 直接塞进所有 tsc -b 流程。如果原工程必须使用增量构建，先找到它实际生成的 .tsbuildinfo，保留后仅移开该项目的构建信息，再用原构建入口重建。文件位置受 tsBuildInfoFile、outDir、rootDir、outFile 等影响，不能一律删项目根目录某个猜出的文件。

构建信息不是运行时 JavaScript；移开它主要增加下次检查工作。无需删除依赖、锁文件、源码或整个缓存目录。CI 若恢复了旧缓存，还要核对缓存键是否区分编译器及配置，避免刚重建又把旧状态带回来。

两个方向都要重新检查

保持源码不变，依次确认“宽库允许、收紧后报错、保持配置仍报错、恢复后消错”。并对每一步比较增量与冷检查结果，不能只验证清缓存后的那一次。

如果冷检查也报同样错误，应继续核对实际标准库、生成配置和所用 API，不再归为旧诊断。不要通过 any、忽略 TS2550 或永久保留更宽的 lib 把不受支持的 API 放过去。采用后续编译器时，也要保留这组配置往返验收，确认旧错误与漏报都已经处理。