面试官：你为什么用 TS，别人用你就用？
前言
面试官盯着简历看了几秒，说：
"你项目里用了 TypeScript？为什么用？别人用你就用？"
我笑了笑，心里想："这都被你发现了，TS 这玩意是跟风就能用得转的吗？"
一、痛点在哪？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 能解决什么？
换个写法，用 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 无法直接感知后端字段变更，但能通过类型系统降低风险
🟢 实际作用：
- 显式契约约束：开发者需手动维护
User类型与后端接口的一致性 - 编译期校验：若代码中误写
user.nome（拼写错误），TS 会立即报错 - 类型提示辅助：IDE 会提示
name字段存在，但无法验证后端真实返回
⚠️ 注意：TS 不能自动同步后端字段变更，需配合以下方案：
- 使用
openapi-generator从 Swagger 自动生成类型定义 - 前后端约定接口变更时同步更新类型文件
- 通过运行时类型校验库（如 Zod）双重保障
三、现实场景对比：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 个月没碰这段代码，也能快速读懂
顺嘴提一句，技术大厂，前后端-测试机会，全国一线及双一线城市均有[坑位]，待遇和稳定性还不错，感兴趣看看。
四、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 世界不得不用它了。
六、TS 是不是更麻烦？值不值？
你可能会说：TS 要定义一堆类型，接口字段一更新就得改类型声明，岂不是很麻烦？
没错，它确实比 JS 多了一步类型维护。但你换来的，是：
- 🚨 Bug 在线上前被发现
- 🧠 代码自带文档，新人也能看得懂
- 🧰 重构有安全感，不怕动一个炸一片
例如你写了这样一段接口类型：
interface User {
id: number;
name: string;
}
使用TS提前定义类型，这是“显式安全”，不是多余的劳动。
反之用 JS 的话：
console.log(user.name.toUpperCase()); // name 是不是 null？你得祈祷
你不知道它啥时候崩，只能靠“测出来”。
而且，很多类型定义可以借助工具自动生成，比如配合 Swagger 的 openapi-typescript，基本不费人工维护。
所以说：TS 是“用类型还债”，早还早安心。
总结
TypeScript 的价值，不是“流行”这么简单，而是：
- 🌟 在开发初期就规避上线 BUG
- 🌟 提升多人协作效率
- 🌟 降低代码阅读与维护成本
- 🌟 强 IDE 支持和重构安全性
- 🌟 更适合复杂项目和长期演进
所以下次别人问你“为啥用 TS”？
请记住：
TS 的价值不是跟风，而是通过类型系统建立代码的‘显式契约’。比如在接口联调中，虽然它不能主动感知后端字段变更，但配合 OpenAPI 生成类型后，能在开发阶段就暴露接口不匹配的问题，避免线上故障。对于团队协作来说，类型定义本身就是最好的文档，能大幅降低维护成本。
感谢评论区指出文章问题✅，笔者TS知识还待学习，感谢包容！
——转载自：不爱说话郭德纲
#我的求职进度条#
CVTE公司福利 935人发布