TypeScript面试：接口数据为什么别急着写成any？

TypeScript 面试：接口数据为什么别急着写成 any？

有人被问到 any 和 unknown 的区别，会先讲「一个更安全」。这句话没错，但太像背定义了。

更直观的说法，不妨直接看一段接口代码：服务端昨天把 name 改成了 displayName，但前端并没有收到通知。结果到了页面渲染时，代码里还在写 user.name.toUpperCase()，白屏问题也不是一打开就暴露，而是等用户点进资料页之后才真正出现。

如果接口返回值从一开始就写成 any，编译器不会拦你：

type User = {
  id: string;
  name: string;
};

async function getUser() {
  const response = await fetch("/api/user");
  const user: any = await response.json();

  return user as User;
}

这里的 as User 没有把数据变成 User。它只是告诉 TypeScript「别问了」。接口返回 { id: 12 }、null，甚至一段错误页 HTML，被它接住以后都能继续往下跑。

面试官如果接着问「那你会怎么改」，就别只回答把 any 替换成 unknown。重点是边界放在哪。

先承认接口外面的数据不可信

response.json() 拿到的是运行时数据。TypeScript 看不到服务端刚刚发了什么，也不能替你判断字段是不是字符串。

我一般让它先停在 unknown，不允许业务组件直接使用：

type User = {
  id: string;
  name: string;
};

function isUser(value: unknown): value is User {
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const item = value as Record;

  return typeof item.id === "string" && typeof item.name === "string";
}

async function getUser(): Promise {
  const response = await fetch("/api/user");
  const data: unknown = await response.json();

  if (!isUser(data)) {
    throw new Error("Unexpected user payload");
  }

  return data;
}

这段代码不是为了证明 unknown 多高级。它的作用很朴素：把「可能有问题」的地方集中在接口层。到了 getUser 外面，调用方只会拿到 User，不用每个组件再做一遍空值和字段判断。

容易答偏的两个地方

unknown 不是运行时校验器。它只是禁止你在没有检查时访问属性。真正拦住脏数据的是 isUser 里的判断。

另外，类型守卫通常只会盯住当前业务真正用得上的那些字段。拿这个例子来说，它并不是要求服务端“只能多返回两个字段”，也不会顺手把复杂的嵌套数组一并查个遍。像订单详情、分页列表这类接口，校验往往会顺着对应层级继续往下展开；要是字段已经多到维护起来很吃力，再考虑把这套校验规则统一收拢、集中管理也不迟。

面试里可以把回答收在这里：

「any 会让不确定的数据直接混进业务代码，问题往往在渲染或计算时才暴露。我会在 API 边界先用 unknown 接住，再通过类型守卫转换成领域类型。这样组件侧拿到的是确定的数据，接口变更也更容易定位。」