👨‍面试官：你为什么用 TS，别人用你就用？

前言

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

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

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

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

先上个例子：

js 复制代码

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 能解决什么？

换个写法，用 TS：

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());
});

🟢 优点立马显现：

后端改了字段？编译器立刻红给你看。
你想访问 user.email？根本不让你点出来。
类型提示、智能补全、接口文档自动化都有了。

是不是感觉代码终于不是"靠猜"来写了？

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

场景一：接口联调

JS 写法：

js 复制代码

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

TS 写法：

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 写法：

ts 复制代码

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

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

✅ 优势：

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

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

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

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

✅ 智能提示 & IDE 体验飞升

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

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

✅ 更强的重构能力

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

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

✅ 更安全地调用第三方库

TS 类型定义让你：

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

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

✅ 复杂逻辑建模能力

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

ts 复制代码

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

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

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

✅ 团队协作更可靠

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

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

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

TS 不是"别人用我就用"，而是：

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

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

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

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

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

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

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

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

ts 复制代码

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

后端改了字段名，TS 编译器会告诉你哪里错了，这是"显式安全"，不是多余的劳动。

反之用 JS 的话：

js 复制代码

console.log(user.name.toUpperCase()); // name 是不是 null？你得祈祷

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

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

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

总结

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

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

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

请记住：我们不是在添加类型，而是在构建未来十年仍可维护的代码基。

下次再见！🌈