前言

面试官盯着简历看了几秒，说：

"你项目里用了 TypeScript？为什么用？别人用你就用？"

我笑了笑，心里想："这都被你发现了，TS 这玩意是跟风就能用得转的吗？"

JavaScript 一、痛点在哪？JavaScript 到底缺了啥？

先上个例子：

function fetchUser(id) {
  return fetch(`/api/user/${id}`) #技术分享
    .then(res => res.json())
    .then(data => {
      console.log(data.name.toUpperCase());
    });
}

看起来正常吧？

但如果后端突然改了字段，把 name 改成了 username ，或者 name 根本是 null ，你就收获了 Cannot read property 'toUpperCase' of null 。

这种问题，JS 根本不会提前告诉你——等你上线才知道错。

TypeScript 二、TypeScript 能解决什么？

换个写法，用 TS：

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

function fetchUser(id: number): Promise<User> { return fetch(`/api/user/${id}`).then(res => res.json()); }

fetchUser(1).then(user => { console.log(user.name.toUpperCase()); });

修正点：TS 无法直接感知后端字段变更，但能通过类型系统降低风险

实际作用：

1. 显式契约约束 ：开发者需手动维护 User 类型与后端接口的一致性
2. 编译期校验 ：若代码中误写 user.nome （拼写错误），TS 会立即报错
3. 类型提示辅助 ：IDE 会提示 name 字段存在，但无法验证后端真实返回

注意：TS 不能自动同步后端字段变更 ，需配合以下方案：

• 使用 openapi-generator 从 Swagger 自动生成类型定义
• 前后端约定接口变更时同步更新类型文件
• 通过运行时类型校验库（如 Zod）双重保障

JavaScript 三、现实场景对比：TS 和 JS 的工作体验差异

场景一：接口联调

JS 写法：

axios.get('/api/user/1').then(res => {
  console.log(res.data.name);
});

TS 写法：

type ApiResponse<T> = {
  code: number;
  data: T;
};

interface User { id: number; name: string; }

axios.get<ApiResponse<User>>('/api/user/1').then(res => { console.log(res.data.data.name); });

优势：

• 自动提示字段类型
• 联调时接口结构变化能及时察觉
• 避免“data.data.xxx”的迷之结构出错

场景二：组件封装

JS 写法：谁知道 props 是啥，靠注释、靠记忆。

TS 写法：

interface ButtonProps {
  text: string;
  onClick: () => void;
}

const MyButton: React.FC<ButtonProps> = ({ text, onClick }) => { return <button onClick={onClick}>{text}</button>; };

优势：

• 参数提示一目了然
• 组件复用更安心
• 哪怕 3 个月没碰这段代码，也能快速读懂

TypeScript 四、TS 的隐藏技能，不止类型系统

如果你以为 TS 只是“JavaScript 加个类型检查”，你就低估它了。

下面这些，是 TS 为开发体验带来的质变：

智能提示 & IDE 体验飞升

• 函数参数和返回值提示
• 对象属性自动补全
• 引用跳转、查找定义、重命名统一处理

配合 VSCode，开发效率简直离谱地高。

更强的重构能力

• 字段名改了？ 自动列出所有引用位置
• 类型系统确保“动一处知全局”

你能自信地“大胆动刀”，而不是“战战兢兢全局搜索”。

更安全地调用第三方库

TS 类型定义让你：

• 不用反复翻文档
• 参数写错直接红
• API 使用一目了然

比如 axios、lodash、dayjs，用 TS 用得飞起。

复杂逻辑建模能力

例如权限系统、表单引擎、配置项类型推导等高级场景：

type Role = 'admin' | 'user' | 'guest';

type Menu = { name: string; roles: Role[]; };

TS 提供联合类型、泛型、条件类型等强大建模能力，表达业务约束比 JS 更清晰。

团队协作更可靠

• 所有函数、组件的“输入输出”都清晰定义
• 新人接手代码有类型指引
• 编译期能发现大部分接口、参数、结构问题

TS 是“写给人看”的代码契约。

五、是不是跟风？其实是趋势

TS 不是“别人用我就用”，而是：

• 项目复杂度上来了，靠 JS 拿捏不住了
• 团队合作中，TS 是最好的沟通契约
• 前后端联调、组件封装、API SDK 全靠它

甚至在你意识到它的价值前，大厂早就用它写好了“脚手架、工具库、接口协议、eslint config”……

不是你跟风，而是 JS 世界不得不用它了。

TypeScript 六、TS 是不是更麻烦？值不值？

你可能会说：TS 要定义一堆类型，接口字段一更新就得改类型声明，岂不是很麻烦？

没错，它确实比 JS 多了一步类型维护。但你换来的，是：

• Bug 在线上前被发现
• 代码自带文档，新人也能看得懂
• 重构有安全感，不怕动一个炸一片

例如你写了这样一段接口类型：

interface User {
  id: number;
  name: string;
}

使用 TS 提前定义类型，这是“显式安全” ，不是多余的劳动。

反之用 JS 的话：

console.log(user.name.toUpperCase());

你不知道它啥时候崩，只能靠“测出来”。

而且，很多类型定义可以借助工具自动生成，比如配合 Swagger 的 openapi-typescript ，基本不费人工维护。

所以说：TS 是“用类型还债”，早还早安心 。

总结

TypeScript 的价值，不是“流行”这么简单，而是：

• 在开发初期就规避上线 BUG
• 提升多人协作效率
• 降低代码阅读与维护成本
• 强 IDE 支持和重构安全性
• 更适合复杂项目和长期演进

所以下次别人问你“为啥用 TS”？

请记住：

TS 的价值不是跟风，而是通过类型系统建立代码的‘显式契约’。比如在接口联调中，虽然它不能主动感知后端字段变更，但配合 OpenAPI 生成类型后，能在开发阶段就暴露接口不匹配的问题，避免线上故障。对于团队协作来说，类型定义本身就是最好的文档，能大幅降低维护成本。

TypeScript 感谢评论区指出文章问题，笔者TS知识还待学习，感谢包容！

下次再见！