网站首页 > 精选文章 正文
前言
面试官盯着简历看了几秒,说:
"你项目里用了 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 无法直接感知后端字段变更,但能通过类型系统降低风险
实际作用:
- 显式契约约束 :开发者需手动维护 User 类型与后端接口的一致性
- 编译期校验 :若代码中误写 user.nome (拼写错误),TS 会立即报错
- 类型提示辅助 :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知识还待学习,感谢包容!
下次再见!
猜你喜欢
- 2025-09-29 看字节大佬教你2021最新的力扣刷题正确姿势是什么?
- 2025-09-29 医院患者陪诊智能体 - Vue3+TypeScript 前端工程
- 2025-09-29 我是如何使用 Vim 高效率写 Markdown 的
- 2025-09-29 欢迎新朋友,通义灵码 AI IDE 来了 | 附 QA 答疑
- 2025-09-29 还有人手动画图?一键生成 Draw.io 流程图,3分钟交作业爽炸!
- 2025-09-29 C++ 开发中 compile_commands.json 与 VSCode / clangd 的关系笔记
- 最近发表
- 标签列表
-
- 向日葵无法连接服务器 (32)
- git.exe (33)
- vscode更新 (34)
- dev c (33)
- git ignore命令 (32)
- gitlab提交代码步骤 (37)
- java update (36)
- vue debug (34)
- vue blur (32)
- vscode导入vue项目 (33)
- vue chart (32)
- vue cms (32)
- 大雅数据库 (34)
- 技术迭代 (37)
- 同一局域网 (33)
- github拒绝连接 (33)
- vscode php插件 (32)
- vue注释快捷键 (32)
- linux ssr (33)
- 微端服务器 (35)
- 导航猫 (32)
- 获取当前时间年月日 (33)
- stp软件 (33)
- http下载文件 (33)
- linux bt下载 (33)