TypeScript 的新 const 类型参数 语法允许函数在不强制调用者到处添加 as const 的情况下保持字面量类型不变，从而减少了最常见的类型拓宽（type-widening）错误。

泛型代码中挥之不去的拓宽问题

当泛型函数接收一个对象字面量时，编译器会将任何字面量属性拓宽为其更宽泛的原始类型。

function call<T>(arg: T) {}
call({ method: "GET" })   // T is inferred as { method: string }

字面量 "GET" 会塌陷为 string。依赖精确值的下游代码——例如可辨识联合类型（discriminated unions）或模板字面量提取——会因此失效，因为类型不再携带精确的字面量。开发者长期以来通过在调用处编写 { method: "GET" } as const 来规避此问题，这告诉编译器保留字面量，但这种修复存在于调用者的手中，而非函数的定义中。

const 类型参数：签名层面的修复

类型参数上的新 const 修饰符告诉编译器为该泛型参数推断出最窄的可能类型。将函数声明为 function foo<const T>(arg: T) 会使 T 自动表现得就像调用者写了 as const 一样。

  • 字符串、数字、布尔字面量 保持其精确值（是 "GET" 而不是 string）。
  • 数组 变为每个元素类型都精确定义的只读元组。
  • 对象 变为深层只读结构，在每个嵌套层级都保留字面量类型。

由于约束存在于函数签名中，每个调用者都能自动受益；忘记进行类型转换不再会导致类型不健全（unsoundness）。

为什么它优于传统的 as const 技巧

as const 是一个调用方侧的解决方案。它要求泛型函数的每个使用者都必须记得添加断言。漏掉一次调用，类型安全性就会消失。const 类型参数将责任转移到了 API 设计本身：函数声明“我需要你传递的任何内容的最小形状”，并由编译器强制执行。

这种转变对于暴露泛型构建器、配置工厂或任何字段字面量值驱动类型逻辑的 API 的库和工具来说至关重要。库作者可以保证正确的推断，而无需监管下游代码。

受益的实际场景

  • 配置构建器 – 环境名称（"dev" | "prod"）保持字面量，从而无需额外转换即可进行可辨识联合类型检查。
  • API 路由定义 – 路径字符串保持精确，允许模板字面量类型提取参数（"/users/:id" → `/users/${string}`）。
  • 状态机助手 – 状态标识符通过方法链式调用保持固定的字面量，防止意外的状态不匹配。

在每种情况下，const 参数都消除了重复的 as const 样板代码，并降低了细微 Bug 溜进代码库的机会。

与 satisfies 运算符配合使用

satisfies 运算符在保留原始字面量信息的同时，验证值是否符合某种结构化类型。将两者结合使用可以兼得两者之长：const 参数提供窄推断，而 satisfies 确保值符合所需的形状。

function makeConfig<const C>(cfg: C) {
  // cfg is inferred with exact literals
}
const cfg = {
  env: "staging",
  ports: [8080, 8443],
} satisfies { env: string; ports: number[] };
makeConfig(cfg); // works, literals stay intact

何时保留 as const

当你控制函数的签名时，const 参数表现出色。如果你处理的是缺少该修饰符的第三方函数，或者你需要为局部变量进行一次性的字面量保留，as const 仍然是正确的工具。它仍然是冻结值而不改变被调用 API 的首选方式。

接下来需要关注什么

该功能还很新，因此工具链和社区模式正在不断演进。可以期待 IDE 支持的更新，在自动补全和快速修复建议中呈现新语法。关注库维护者：许多人将开始把公共泛型迁移到 const 参数，这可能会为之前依赖显式 as const 转换的代码引入破坏性变更。

总结： 通过将字面量保留直接嵌入到函数的类型参数中，TypeScript 的 const 类型参数消除了常见的拓宽错误来源，并将安全性从调用者转移回了 API 设计者。对于你拥有的任何泛型入口点，请使用它们；将 as const 留给局部值或外部 API。