在讲这个故事之前，先说我的观点：做技术选型，一定要结合团队现状来做出选择。这里的团队现状主要包括：你自己的技术能力、团队其他成员的技术能力、时间、管理方案、沟通结果、维护成本、技术方案本身的优缺点。
总能把技术用在适合他的地方，才是一个成熟的架构师应该追求的能力。而不只是追求技术本身。
故事
昨天接到一位粉丝朋友的付费求助。他是某个团队的前端 Leader，手底下管了 7 个前端小伙伴，但是最近一段时间，由于管理不善，被老板多次当面批评，他感觉自己已经面临被裁员的风险，所以很慌，找我咨询应该怎么办。
我详细了解了他的情况，然后发现，一切的原罪，居然是因为他一意孤行，在团队中强推 TypeScript。
最开始的时候，由于自己没有使用 TS 的经验，但是架不住在跟别人交流的时候，有人狂吹 TS，因此他觉得，自己还没用过 TS 是一种落后，于是，萌生了在项目中推行 TS 的想法。
但是在开会公布这个决定的过程中，遭到了几个小伙伴的反对。他们觉得虽然 TS 有很多好处，但由于担心自己不会使用，因此心里没底。好在他在团队中还是比较强势，因此最终推行 TS 这个决定还是执行了下去。
在执行过程中，就遇到了大量更具体的问题。
1、错误评估了老项目升级的工作量 2、小伙伴有问题需要他解决时，他也没办法解决掉，从而导致了信任危机 3、关于 TS 的严格程度一直没有一个稳定的认知，制定的规范无法切实可行的落地，从而导致了内部矛盾加剧 4、需求多次 delay，最终爆雷
公司层面认为整个前端团队的工作态度出了问题，因此着手处理这个问题，最后下面几个小伙伴都认为是他强推 TS 导致的，从而被判定为他的综合能力有问题，他自己也无话可说。
很显然，经历了这个事情，他在团队中的个人形象，无论是对上，还是对下，都受到了严重的破灭，可以说是一个非常惨痛的教训。
那么，如果我们缺乏丰富的 TS 经验，在推行 TS 的过程中，应该怎么做呢？
一、搞清楚 TS 的本质
TS 的本质就是，他仅仅只是一个静态类型检测工具。他并不参与代码的运行。这里代表的含义就是，就算是我写的 TS 代码出现了严重的报错，我们的程序依然可以正常的被编译成 JS 然后成功运行。
这是和其他强类型语言很不一样的地方。也就意味着，我的代码报错还是不报错，实际上就有了很多退让的空间。因为就算代码报错，也不影响运行。
于是，TS 代码怎么写，规范应该怎么制定，就有了太多的可讨论的空间。
例如，我有一个函数，用于计算传入数字与 20 相加
对于开源项目/大团队内部公共项目而言，由于你无法控制使用者的传入习惯，有的人、团队可能就算是 TS 代码报错，也能容忍。因此，你的 TS 代码就不能直接这样写
!这样的开发者其实还不少
因为就算是我传入奇怪的入参，TS 也报错了，但是很多人无所谓。于是这样的项目，要确保类型的强大，又要确保类型安全，就必须老老实实的做体操，去兼容奇怪的传入，例如，兼容一些别的类型
但是如果你没把控好这个本质和初衷，你也觉得你的 TS 也应该这么写，那就走远了，你的开发工作量和对 TS 的掌控难度就要高非常多。
如果在可控范围以内，我们能够通过团队规范和约定限制传入类型呢？这样写，就是最佳方案与最简单的用法。
因此，当你的 TS 能力还不够纯熟时，你完全可以在团队使用第二种思维方式，通过限制传入类型来简化 TS 的应用难度。
二、约定其他的规范进一步简化 TS 的难度
有了这个大前提，我们已经在很大程度上避免了类型体操的操作。于此同时，我们需要判断你的 TS 项目是否会对外开发，只要不对外开放，我们还可以约定更多的规范来简化 TS 的使用难度。
例如
1、不使用 JS 标准中不支持的语法，例如枚举、public、private、重载等
2、尽量直接完整的写类型，少使用 extends、交叉类型、联合类型等各种组合的方式生成类型
3、尽量利用类型推导来约定类型
4、暂时放弃或者简化对参数为函数的类型约定。这是因为当参数为函数时，类型兼容性的判断可能会涉及到逆变与协变，理解起来比较困难，也可以用 any 代替
5、允许使用 @ts-ignore，并且学会通过这种方式，中断/改变三方开源库的类型推导
6、在合适的地方，强制使用 as 简化类型
...
✓虽然我更多的是建议是在还不熟练的时候定义这些规范，但是用久了之后你会发现如果你的项目场景没有变化，这些规范也可以一直用下去
三、推广方式一定要范围可控
由于 TS 的特殊性，我们可以先小范围开始推行 TS，而不是直接在整个大项目中使用。
这里的小范围包括人和需求。
一、在团队中选择个别优秀的成员开始实践，也可以你自己先实践，不要着急全团队推广。在你自己还不熟练的时候，全团队推广非常容易让你的个人形象受到严重的打击。
二、先在单独某个需求中试点。必须要确保不影响整个团队的开发进度。
三、在这个试用阶段沉淀好使用经验之后，再全团队推广。
总结
任何技术方案都并不是非他不可，包括我最近在公众号力推的 React 19 与 tailwindcss。虽然我个人能够感受到他们带来的好处，但是也只是从分享他们的使用体验的角度出发，来给大家分享这种方案的真实感受。
但是我从来没有去下一个结论说，都要 2025 年了，你还没有用 react 19 你就 out 了。如果我在分享我的使用体验的过程中，你也感觉到了这个好处，然后自己去试用和体验，形成自己的使用经验，这才是我最根本的目的。
✓当前阶段学习 React 19 的目的，更多的好处是体现在面试和晋升中吹牛逼，如果在实战中顺利运用，则对开发者的技术能力有更成熟、更完整的要求
任何技术方案的选择和改变，不管别人怎么吹，但是落地到具体实践中，都有可能涉及到沉重的代价。 因此，结合团队场景准确评估技术方案是一名资深开发者需要具备的能力。这也是为什么许多同学在面试中，经常会被问到为什么要选择某某技术方案的原因
推荐阅读
掌握 React 19，推荐付费小册 《React 19 全解》成为 React 高手，推荐 《React 哲学》夯实 JS 基础体系，推荐 《JavaScript 核心进阶》
