TypeScript unknown 和 any 怎样选择

在读取接口响应、解析 JSON 或接入一段旧 JavaScript 时，我经常看到两种写法：把值标成 any，让代码先通过；或者把值标成 unknown，直到确认它是什么再继续使用。我的选择很明确：不确定的数据先用 unknown，只有为了隔离遗留接口才暂时使用 any。前者保留类型收窄的安全边界，后者会主动放弃这一层提醒。

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

下面的比较围绕一个实际结果展开：让类型风险停留在输入边界，而不是沿着函数参数、返回值和对象属性一路扩散。

先分清 unknown 和 any 的承诺

unknown 可以接收任何值，但不能直接读取属性、调用方法或当成具体类型传给函数；必须先用 typeof、相等判断、in 或自定义类型守卫完成收窄。any 则相当于告诉编译器“这里由我负责”，读取不存在的属性、调用不存在的方法通常都不会在这一层报错。

在外部数据边界使用 unknown

以一个不受我们控制的用户资料响应为例，入口只承诺“这是某个值”，判断逻辑集中在一个类型守卫里。这样做的好处是，业务函数拿到 Profile 后就不必重复猜测字段。

type Profile = {
  id: string;
  displayName: string;
};

function isProfile(value: unknown): value is Profile {
  // 先排除 null，再确认对象字段的运行时类型。
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const record = value as Record;
  // 只把真正满足字段约束的值交给业务层。
  return typeof record.id === "string"
    && typeof record.displayName === "string";
}

function getDisplayName(payload: unknown): string {
  // 外部输入先经过守卫，失败时返回明确的降级结果。
  if (!isProfile(payload)) {
    return "未命名用户";
  }

  return payload.displayName;
}

这里的 as Record 只存在于边界判断内部，并没有把整个输入直接断言成业务对象。真正让 TypeScript 放行的是类型谓词 value is Profile，它把运行时检查结果传递给后续控制流。

any 为什么短期顺手，长期容易失控

我在维护旧模块时也会遇到必须先接入的 any，但会把它限制在一个很小的适配函数里。下面的写法看似省事，实际上把错误推迟到了运行时：

function readLegacyName(value: any): string {
  // any 会允许不存在的属性和方法一路通过编译器。
  return value.profile.name.toUpperCase();
}

const payload = { profile: { name: "Lin" } };
// 一旦上游字段改名，问题通常要到这条调用路径运行时才暴露。
const name = readLegacyName(payload);

更麻烦的是，any 会传染：一个返回 any 的函数会让调用方继续失去属性检查，赋给变量、数组元素或泛型参数后，风险边界会越来越模糊。它适合表达“这个旧库的类型声明暂时缺失”，不适合表达“我还没有想清楚这个输入是什么”。

我的落地规则：unknown 在边界，any 在隔离区

可以把选择压缩成四条经验：

• 数据来自网络、表单、存储或插件时，入口先标成 unknown，再做结构判断。
• 已经明确的业务数据直接定义接口，不要用 any 代替建模。
• 旧库只能提供 any 时，在适配器里接住它，并尽快转换成具体类型或 unknown。
• 如果只是为了让当前文件通过检查而写 any，先问自己能否用联合类型、泛型或类型守卫表达真实边界。

迁移旧代码时不必一次改完。先把 any 的入口集中到一个函数，再让函数的返回值变成 unknown；随后补上字段检查，最后把检查后的对象替换为领域类型。每一步都缩短不确定性的传播距离，通常比全项目盲目替换更容易控制回归范围。

常见问题

unknown 能不能直接赋给 string？

不能。先用 typeof value === "string" 或自定义守卫完成收窄；如果业务确实掌握额外不变量，也应把断言限制在靠近边界的位置，并说明它依赖的前提。

any 是不是完全不能用？

不是。第三方旧库、逐步迁移的 JavaScript 模块和确实缺少类型声明的接缝处可以短期使用，但应该有清晰的适配边界，避免让 any 成为公共 API 的参数或返回值。

TypeScript 官方文档对类型收窄、控制流分析和类型守卫有更完整的说明：https://www.typescriptlang.org/docs/handbook/2/narrowing.html。把 unknown 当作需要证明的输入，把 any 当作需要隔离的债务，通常就能做出稳定选择。