选型没有最佳实践，因为每个项目所处的场景都是不一样的。 具体技术选型方案好坏，例如“为什么要选择React而不是Vue?”之类的文章网上已经很多了，这里不多讲。
本文主要谈一些选型原则和技巧，也就是说“道、法、术、器”中，我们聊的是“术”。
这几年工作中，除了自己做的技术选型外，还看了网上非常多的技术选型相关的文章。今天，我总结出以下几条最佳实践👇
基于业务场景
业务是目的，技术是手段。
技术服务于业务，并在伴随业务一同演变、成长。所以，要结合业务自身特点以及未来业务的可能演变方向来开展技术选型。
B端业务比较重，需要侧重的点是开发效率和长期的可维护性，这时候选择一些比较成熟的技术栈是比较好的选择。而C端业务更加注重用户体验，为了降低页面加载的白屏时间需要选择做SSR。
有的业务（设计到金额、结账之类的）会经常处理数字，在这种场景下TypeScript相对于ES6来说会是更好的选择。
基于团队能力
成员之间差异
团队由许多的个人组成，每个成员的技术能力、技术偏好存在一定的差异。所以在选型时，要考虑这些差异加以权衡。
是否有助于团队成长
团队如同一个孩子，挑食会导致影响不良，均衡的技术栈能让人更好地成长，所以技术选型要考虑是否有助于团队的成长。
如果团队都是React项目的，可以考虑在一些边缘项目或者简单的C端项目引入Vue，对整体技术体系冲击不大同时团队也有了Vue的能力储备。
与已有的整体相协调
- 要考虑迁移成本。
- 新的选型最好与旧体系相协调，协调意味着新、旧能够共生，而不会产生较大的破坏力。
新的技术体系引进来之后，是否要对老项目进行迁移，迁移会产生多少的成本。
选型处理要与团队已有的技术栈相协调之外，在公司范围内，选型需要考虑与公司整体的技术栈相协调（不一定要强一致调）。协调的好处有很多，例如：可复用性方面，其他团队的轮子可以直接接入到项目中，本团队有的轮子可被其他团队复用。
降低成本、提高效率
Focus on ROI.
技术本身是一种工具和手段，而工具和手段应该关注成本和效率。
换而言之，技术选型需要考虑ROI。
- 降低成本要求做相同的事情投入更少；
- 提高效率要求付出相同的时间产出更多。
所以，选型要考虑如果降低成本、如何提高效率。好的ROI，也可能让你有一个好的KPI。
比如：上手难度要在允许可能范围内降到最低。一个项目往往会有很多的人参与开发，上手难度越低越有助于项目开发。
长期可维护
Think in longterm, do it in shortterm.
这里只谈——长期可维护，因为：
短期而言，所产用的技术都是比较热门的、知名度高、社区活跃，不存在可维护问题。
很多技术都是盛极一时，落伍的技术栈会导致维护成本增加，所以，选型时要考虑到项目的长期可维护性。长期可维护性需要考虑下面几个点：
- 所采用技术的社区生态是否完善、周边配套工具是否完善。
- 是否有人在维护，是否是大公司发起和采用的。
- 选择较为稳定的。激进的框架变化非常快，看起来增加好多新能力，但是实际上需要用户频繁更新，一年没更新就落后很多，更新起来又有风险。
满足现在，兼顾未来
想得远，才能走得远。
技术选型时，“满足现在”这点基本上大家都能做到，但是“兼顾未来”是很多人所忽略的，因为很多人是短视的或者根本不思考未来的演变。
如果不前瞻未来，有时会产生以下问题：
- 技术选型马上面临淘汰，维护成本攀升。
- 技术选型不能满足未来业务发展的需要，需要再次更换技术选型并重构。
一切从简
Simple is powerful!
切记，能简单的不要复杂，更不要过度设计。
杀鸡焉用牛刀，对症下药才是正确的。很多时候，技术人员喜欢在选型时把许多牛bi的东西都加进来，实际上用处不大、可有可无，反而会增加维护成本。
所以在选型时，尽可能保持技术选型的简单。最简单的，才最可持续。
其他一些思考
- 团队规模越小，技术越要收敛。同时如果团队未来会扩大，则选型时要考虑到这一点。
- 借力业界的最佳实践。充分利用业界的最佳实践，在此基础上结合业务场景加以创新。
- 商业化需要考虑法律问题，这不是开玩笑。对于要拿出去卖的东西，要考虑著作权保护。遇到“BSD+专利许可证”的开源项目，采用就要谨慎考虑了。
- 大型公司内技术团队的技术选型较为简单，小公司考验团队的技术选型。大公司基本都会要求使用公司统一的技术体系，参考其他团队的选型少做调整即可。