我第一次“遇见” TypeScript 时的心声是：这玩意儿到底是 JavaScript，还是另起炉灶的一门新语言？

查明之后，答案更像是：带增值服务的 JavaScript。

“静态类型！编译期报错！智能提示！” 当场心动：何不试试？体内的完美主义者按捺不住，于是挑了个小项目开刀，只为体验那层“类型安全的光晕”。

三年快进。热情被现实磨平——TypeScript，或许被过度吹捧了。对吗？

承诺 vs. 现实

TypeScript 许下了不少好处：

• 静态类型，在问题上线前将其拦截；
• 类型即文档，接口自解释更清晰；
• IDE 友好，自动补全、重构与跳转更丝滑。

听上去近乎理想国。然而，它修补的并非最常把应用搞崩的那类问题。

• 业务逻辑错误、第三方 API 的运行期“幺蛾子”、以及 异步流程缠绕——TypeScript 触及有限，甚至无能为力。 换言之，它不是魔杖；它更像护栏：能防一些事故，但并不能代你开车。

当调研把话挑明

微软（TypeScript 背后的东家）一再强调：最大红利主要出现在超大型企业级工程，也就是数百名开发者共同维护同一代码库的场景。

更小团队呢？收益往往有限，甚至边际效应递减。

再看 2023 年 State of JS 的调查：大约只有三成多（约 36%）的 JS 开发者真切地感到 TypeScript 提升了安全性。

更糟的是，不少人体验到的“安全感”只是错觉。

我亲眼见过同事把几小时“耗”在 any 与类型声明上：不是补第三方缺失的类型包，就是在复杂泛型上打结。半天时间，葬在“类型体操”里——字面意义上的。

现代 JS：其实已经“够用”

一个常被忽略的事实是：现代 JavaScript（ES6+）已经把“八成刚需”摆在你案头：

• 箭头函数、模块化、解构、展开与剩余参数；
• 可选链与空值合并；
• Promise 与 async/await 驾驭异步流程。

再搭配 ESLint、单元测试，以及 运行期校验（如 zod），你已经覆盖了 90% TypeScript 吹嘘的“安全面”。看个例子：

import { z } from "zod";

const userSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});

function greet(user) {
  const parsedUser = userSchema.parse(user);
  console.log(`Hello ${parsedUser.name}`);
}

没有静态类型、没有编译负担，却能在运行期把真正会让程序跌倒的问题（例如“字符串冒充数字”）牢牢拦下。

你不需要 TypeScript，才能发现“用户把 age 传成了字符串”。

何时 TypeScript 得不偿失

我的亲历：团队里新同学要上手一套 TS 泛型爆炸的工程，入门曲线陡得离谱。

• 微妙的类型不匹配让他卡了半天——运行期其实毫无影响；
• 构建时长变长、CI/CD 变慢，开发节奏被拖累；
• 工程渐渐长成了“驯服编译器的大怪兽”。

后来，我们把项目改回 Vanilla JS，流程反而顺畅。 对中小型项目而言，TypeScript 常常像是一副“黄金手铐”：

• 大家为了过编译器，在代码里**满天飞地撒 any**；
• 一旦如此，初衷被自我否定——你要的“类型安全”，最后只剩一层“纸糊防护”。

TypeScript 的真正舞台

话也不能说死。TypeScript 依然有自己的“主场”：

• 超大型企业级代码库（多人长期协作、模块互锁复杂）；
• 公共库或框架（需要严谨的公开 API 合同与演进稳定性）；
• 生命周期很长的产品（重构频繁，类型能降低“牵一发而动全身”的风险）。

但对多数团队在做的 SaaS 应用、营销站点、或中等体量的 SPA？它常常是“负担多于护益”：学习成本、迭代成本与构建成本都必须算清楚。

总结

我愿意直说：“纯 JS 已经足够，甚至绰绰有余。”在大多数真实世界的工程里，现代 JS + Lint + 运行期校验 + 单测，可以解决 90%–95% 的痛点。

• 你的代码不会因此坍塌；
• 你的 Bug 不会因此暴增；
• 开发者每天早上也不必先与编译器“互殴”一小时再开工。

所以，与其追逐 TypeScript 梦，不如拥抱 JavaScript 的简洁。

​

阅读原文：https://mp.weixin.qq.com/s/Rxc3Kqk5ivyD81egvZv9kw