前端圈这几年有个很奇怪的现象。

一边是技术文章天天在讲，TypeScript 是未来，不用就是落后。
另一边是一线开发者，在项目里一边写 TS，一边到处写 any。

最后形成一种荒诞局面：

类型看起来很严谨，代码跑起来全是问题。

这不是个别现象，这是常态。

国内前端项目的真实节奏

很多人讨论 JS 和 TS，是站在一种理想环境下：

需求稳定，有时间设计，有时间抽象，有时间慢慢打磨类型。

但只要你在国内公司待过，你就会知道真实情况是什么样。

一个项目的标准流程通常是这样：

今天立项，明天出 UI，后天开始写代码，一周之内必须上线第一版。

如果你以为上线就是结束，那说明你还没被项目教育过。

上线只是开始。

上线之后，才是真正的开发

上线之后你会面对什么？

产品开始改需求，后端开始改接口，老板开始推翻逻辑。

有时候甚至第一版刚上线，就直接推翻七成重写。

而且不是一次，是反复来。

在这种环境下，代码的核心诉求只有一个：能快速改，能快速上线。

在这种环境下，TS 会放大痛苦

很多人以为 TS 是来提升代码质量的，但在国内项目里，它更多时候是在放大修改成本。

举个非常真实的例子。

后端接口一开始返回的是 name 字段，后来改成了 nickName。

在 JS 里，你只需要改一行代码。

在 TS 里，你要改接口定义，改类型引用，改函数签名，甚至改一整条依赖链。

屏幕上一片红。

这时候，大多数人的选择不是优雅地重构类型，而是写下一行代码：

const user: any = res.data;

写下这行代码的那一刻，其实已经说明了一件事。

你并没有在用 TS，你只是把 JS 套了一层壳。

国内项目真正的核心矛盾

很多人把问题归结为代码质量，其实根本不是。

国内前端的核心矛盾只有一个，就是时间。

你每天面对的是截止时间，是不断变化的需求，是不稳定的接口，是随时可能推翻的方案。

在这种情况下，灵活比严谨更重要。

所以结论其实很简单

业务代码用 JS，工具代码用 TS。

如果你在写一段代码的时候，开始犹豫要不要用 TS，那就直接不用。

因为真正需要 TS 的地方，是不会让你犹豫的。

为什么业务代码更适合 JS

业务代码的本质，是变化。

今天这样写，明天可能就推翻。

你用 TS，会出现一个很典型的现象。

类型刚写好，需求变了。
类型刚稳定，接口改了。
代码还没多少，类型已经一大堆。

你会发现自己每天在做的事情，不是写业务，而是维护类型。

举个很常见的例子。

一个表单提交逻辑，用 JS 写就是一行请求。

用 TS 写，一开始看起来很规范，但只要字段稍微变一下，你就要跟着改类型、改调用、改校验。

改着改着你就会意识到一件事。

你不是在提高效率，而是在增加负担。

TS 真正应该出现的地方

TS 并不是没用，它只是被用错了地方。

它真正适合的是那些一旦出错就会影响很多地方的代码。

比如工具函数、公共库、SDK 封装、复杂的数据处理逻辑。

这些代码有几个特点。

复用率高，调用方多，生命周期长，一旦出错影响范围大。

在这些地方，TS 的价值才会真正体现出来。

它可以在编译阶段直接拦住错误，而不是等到线上才出问题。

强行全 TS，是很多团队的问题根源

很多公司喜欢搞一种看起来很“高级”的策略。

新项目必须全 TS。

听起来很专业，但落地之后会发生什么？

初级开发到处写 any，中级开发写不动复杂类型，高级开发在维护一堆没人敢动的类型系统。

最后项目变成一个看起来很规范，但实际维护成本极高的东西。

代码不是不能改，而是没人敢改。

真正成熟的选择方式

成熟的团队不会纠结用不用 TS，而是只关心一件事。

用在什么地方。

该快的地方，就让它快。
该稳的地方，就让它稳。

业务代码追求的是速度，工具代码追求的是安全。

最后说一句更扎心的

很多人以为自己在用 TS 提升代码质量。

其实只是用复杂的类型，掩盖自己对业务的不理解。

真正厉害的人，反而很简单。

该用 JS 的地方毫不犹豫，用到极致。
该用 TS 的地方绝不含糊，用到精准。

一句话总结

国内前端的本质，是一边开发，一边变更，一边推翻。

在这种环境下，JS 是生存工具，TS 是精密仪器。

大多数人不是不会用 TS，而是用错了地方。

最后，如果你是用AI写的，那当我没说。