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