问题描述
如何选择新的技术栈几乎所有团队都经历过技术选型问题，不管是大层面的基础设施选型，还是小到第三方服务的使用，开源项目百花齐放的今天，相同问题往往不止一种解决方案。如何才能正确选择，少挖坑，是件有趣的事情。
需要考量的因素
业务，团队成员，技术技术选型其实并非一个单纯的技术问题，相反技术平台本身的考量往往是放在最后面的。首先需要考量的是业务本身的特殊性，再结合团队成员的诉求与能力，最终才在技术方案间做个选择题。
业务考量
所有脱离业务需求的技术方案，都是耍流氓技术选型是一个小马过河的故事，厂家宣传的再怎么天花乱坠都好，只有真正契合业务上下文的方案才是好的方案，而每个项目都有自己的特殊性，选型者作为掌舵人，需要把项目上下文尽可能了解清楚，找出项目成败最核心的1到2个标准，以此作为基础来做选择题。譬如说，创业项目，灵活是明显的述求，产品推出后必然会面对朝令夕改的需求，如何快速反应是选型的重点。再譬如说，陈年项目性能遇到瓶颈需要重构，再往下挖可能原有系统吞吐量不成问题，但瞬时响应太差，选型时就需要特别注意这个点。以此类推
团队成员
最终的执行人是成败的关键选择的方案需要充分考虑团队成员的技术构成。手头有几把枪，什么枪，未来多长一段时间可以有几把枪，什么枪，需要心中有数。另外，方案的选择需要在核心人员间充分沟通，互通有无，对后期的落地也会更顺利些。
技术考量
多对比，多试验对以上两个考虑因素有了充分理解后，技术考量反倒是相对容易的事情。多看，多试验，“按部就班”，即可
尽可能多的罗列出现有解决方案
多数场景下我们所面对的问题，业界都有人面对过，在闭门造车之前，先寻访下现有的解决方案。
技术前景如何？
技术前景是一个需要优先考量的因素，有些技术看起来性感无比，让你恨不得立刻使用起来。但可能非常小众，此时就要非常谨慎，没准项目还没有结束，选用的解决方案就太监了。
社区是否足够活跃？
社区活跃度是技术前景的一部分，需要重点考量。可以通过查看Github的star数，issue数量，问题修复时长，新版本更新进度；Google Trends；stackoverflow问题数量；文档是否健全；配套的生态是否完整；国内社区论坛版块等查看
是否有大厂使用，是否有成熟的案例
站在巨人的肩膀上，自然能看的更远。（当然，也可能摔的更痛，这就是另一个话题了）。成熟案例也是社区周边成熟的一个风向标，如今多数团队都会分享自己的部分解决方案，google之，能从中得到许多信息。
技术特性
本身的易用性、可维护性、可扩展性、学习成本等。初步选定后，多写点DEMO，多试验
黑历史
技术领域不存在可以解决一切问题的银弹，选型前需要先了解下技术栈的黑历史。正反用例都需要接收
开源协议约束
开源项目都会有自己的协议规则，决议前需要了解清楚，避免往后的麻烦。
profile
这是个需要特别注意的点，没有人能保证一个方案万无一失，一旦出问题，是否有兜底方案，是否能快速strace到问题，profile到热点显得尤为重要。
性能
信息爆炸的今天，软文无数，压测还是要自己跑跑。
最后，还有个魔鬼需要面对
新技术之于技术人员，就好比新包包之于妹子，似乎每一个技术人员都对新技术有天然的冲动。
瞧！多么优雅，多么性感，马上用起来！
千万别！
有时候开发人员自己玩的很high，但项目却玩死了。这是件很悲哀的事情，我们需要抑制内心深处的魔鬼，技术只有跟业务有机的结合起来，产出所追求的价值，才是有意义的。
拾零散记公众号
