TypeScript不是万能钥匙，用错地方反而添堵，到底该不该上？
最近帮公司一个老项目做技术评估，发现大家对TS的态度特别两极。有人觉得不用TS就是不专业，有人写个按钮都要查半天泛型怎么写。我翻了几十个真实案例，包括京东云、Vue官方团队、还有几个小团队的踩坑记录，发现根本问题不是“JS烂不烂”，而是“你现在卡在哪”。
项目刚上线那会儿，三个人天天挤在会议室改bug，连接口字段叫啥都靠猜。后来加到六个人，光是解释一个购物车数据结构，每天就得花半小时。这时候TS才真正显出作用——不是因为它多酷，而是它能让代码自己说话。比如`order.status`后面自动弹出`'paid' | 'shipped'`，不用再翻文档、问后端、看历史提交。
但真要上TS，得先看清楚自己是不是真需要。见过最冤的，是老板拍板做两周MVP，技术负责人当天就配好TS环境，结果第3天发现连jQuery插件都没类型定义，一堆`// @ts-ignore`盖得比注释还密。最后代码没跑通，人先累趴了。TS不是考试加分项，它解决不了“人没聊清楚需求”这种事。
还有一个容易被忽略的点：团队里一半人连解构赋值都写不利索，硬推TS只会让新人天天截图问“这个红波浪线怎么关”。云开发者社区2021年有个调研，小团队强推TS后三个月内离职率涨了23%，不是因为TS难，是因为没人教怎么一点点来。
其实完全不用一步到位。我试过最省劲的办法：先把所有`.js`改成`.ts`，加一行`// @ts-check`，配合JSDoc写几个参数类型，IDE立马能提示错了。不改构建流程，不碰webpack，连打包都还是原来那样。这招我们叫“假装有TS”，但真能拦住80%低级错误。
第二步才开始挑重点补。比如后端给的用户接口，就建一个`User.ts`；商品列表组件接收什么props，就写个`ProductListProps`。不求全，只保核心。过程中允许用`any`，但必须写`TODO: TS`备注，不然过俩月谁还记得这地方该改。
最难的其实是第三步——不是写法难，是习惯难。比如原来随便`res.data || []`，现在得想清楚`res`有没有`data`字段，`data`是不是数组，空的时候返回啥。这时候TS逼你把业务逻辑理一遍。有次我们改一个订单状态流转，光是定义`OrderStatus`就讨论了四十分钟，但改完之后，三个月没再出现状态错乱的bug。
TS最大的好处，不是编译时报错，而是让新来的哥们打开编辑器，鼠标往`api/fetchUser`上一悬停，立刻知道要传id、返回user对象、失败会throw什么错误。不用找文档，不用问人，甚至不用读源码。一个接口，五种用法，以前靠口口相传，现在全写在类型里。
有些团队用着用着就变了。他们开始把业务词直接写进类型名，比如`type RefundReason = 'quality' | 'logistics' | 'other'`，而不是`string`。后端改个枚举值，前端立刻能发现。联调时间从两天缩到两小时，不是因为工具多牛，是因为大家终于用同一种语言在说话。
上次我们一个实习生，入职第三天就改了个关键接口的类型定义，顺便揪出后端漏返回的字段。他没看过整个项目，但看懂了类型，也就看懂了业务。这不是TS多厉害，是类型把模糊的东西变清楚了。
但真没必要为了TS而TS。有个做后台管理系统的团队，就俩人维护，所有库都是自己写的，JS注释写得比TS类型还全，半年没出过类型相关bug。他们没上TS，不是不会，是没必要。
技术选型不是比谁配置文件写得长，而是看现在哪块卡脖子。协作乱、重构怕、新人懵、bug总在奇怪地方冒出来——这时候TS才真正有用。
用不用TS，不看别人，只看你今天早上改的那个bug，是不是又是因为传了个字符串当数字。
就这。
