TypeScript 5.8 于 2025 年 2 月发布（注：这里指向实际项目中采用的版本）。经过几个月的生产使用，来分享一些真实场景下 TypeScript 严格类型系统的实践经验——哪些新特性真正有用，哪些在大型项目中会带来意外麻烦。

TypeScript 5.8 主要特性回顾

1. --erasableSyntaxOnly：为 Node.js 原生 TS 支持优化

Node.js 22+ 支持直接运行 .ts 文件（不生成 .js），但只支持"可擦除语法"（不允许 enum、namespace 等运行时语法）。TS 5.8 新增 --erasableSyntaxOnly 选项来检测违规：

// tsconfig.json（用于 Node.js 原生 TS 项目）
{
  "compilerOptions": {
    "erasableSyntaxOnly": true // 禁止 enum、namespace 等运行时语法
  }
}

// ❌ 报错：enum 不是可擦除语法
enum Status {
  Active,
  Inactive,
}

// ✅ 替代方案：const 对象 + 类型
const Status = {
  Active: "active",
  Inactive: "inactive",
} as const;
type Status = (typeof Status)[keyof typeof Status];

// ✅ 替代方案：string literal union
type Status = "active" | "inactive";

2. 条件类型中的 infer 改进

// TS 5.8 之前：提取函数返回类型的 Promise 内层类型需要嵌套 infer
type UnwrapPromise<T> = T extends Promise<infer U> ? U : T;
type UnwrapAll<T> =
  T extends Promise<infer U>
    ? UnwrapAll<U> // 需要手动递归
    : T;

// TS 5.8：infer extends 语法更强大
type ExtractArrayItem<T> = T extends (infer Item)[]
  ? Item extends string
    ? `string:${Item}`
    : Item
  : never;

// 更实用：提取 API 返回类型的精确形状
type ApiResponse<T extends (...args: any) => any> =
  Awaited<ReturnType<T>> extends { data: infer D } ? D : never;

// 使用示例
async function fetchUser(id: string): Promise<{ data: User; meta: Meta }> {
  return await api.get(id);
}
type UserData = ApiResponse<typeof fetchUser>; // User

生产中遇到的 TypeScript 严格类型问题

问题 1：noUncheckedIndexedAccess 与数组操作

// tsconfig.json
{
  "compilerOptions": {
    "noUncheckedIndexedAccess": true  // 开启后：数组访问返回 T | undefined
  }
}

// ❌ 开启后，之前没问题的代码报错
function getFirst<T>(arr: T[]): T {
  return arr[0];  // 报错：Type 'T | undefined' is not assignable to type 'T'
}

// ✅ 修复方案 1：断言
function getFirst<T>(arr: T[]): T {
  return arr[0]!;  // 非空断言（需要确认数组非空）
}

// ✅ 修复方案 2：更安全的写法
function getFirst<T>(arr: [T, ...T[]]): T {  // 至少一个元素的元组
  return arr[0];
}

// ✅ 修复方案 3：明确处理 undefined
function getFirst<T>(arr: T[]): T | undefined {
  return arr[0];
}

实践建议：在大型项目中启用 noUncheckedIndexedAccess 会产生大量需要修复的报错，建议先在新模块中试用，而非全量开启。

问题 2：satisfies 运算符的性能开销

// satisfies 在复杂对象上会有显著的类型检查性能开销
// 特别是在大型配置对象中

// ❌ 在大型对象上大量使用 satisfies 会拖慢 tsc
const config = {
  routes: [...],  // 1000+ 路由配置
  plugins: [...], // 100+ 插件
} satisfies AppConfig;

// ✅ 在性能敏感场景，改用类型标注
const config: AppConfig = {
  routes: [...],
  plugins: [...],
};

问题 3：template literal 类型的递归限制

// 深层嵌套的 template literal 类型会触发 TS 的递归限制
type DeepPath<T, Prefix extends string = ""> = T extends object
  ? {
      [K in keyof T]: T[K] extends object
        ? `${Prefix}${K & string}` | DeepPath<T[K], `${Prefix}${K & string}.`>
        : `${Prefix}${K & string}`;
    }[keyof T]
  : never;

// 对于超过 4-5 层的对象，TypeScript 会报 "Type instantiation is excessively deep"
// 实践：限制深度或使用运行时方案（zod、yup）替代复杂的类型推导

有价值的 TS 5.8 新能力

// 1. 更智能的 control flow narrowing（自动 narrowing 从未如此精准）
function processValue(val: string | number | null) {
  if (val === null) return;
  // 5.8：val 在复杂分支中的类型推断更准确
  const result = typeof val === "string" ? val.toUpperCase() : val.toFixed(2);
  // result: string（5.8 正确推断联合类型各分支的结果类型）
}

// 2. decorator metadata 改进（配合 Angular/NestJS）
// TS 5.8 更好地支持 Stage 3 装饰器的 metadata 访问

总结

TypeScript 5.8 延续了 5.x 系列"持续打磨边界情况"的节奏，没有颠覆性变化。对生产项目最有价值的是 --erasableSyntaxOnly（准备 Node.js 原生 TS）和改进的 control flow narrowing。noUncheckedIndexedAccess 理论上更安全，但大型项目引入代价较高，建议在新模块中逐步试用。