問題描述
如何選擇新的技術棧幾乎所有團隊都經歷過技術選型問題，不管是大層面的基礎設施選型，還是小到第三方服務的使用，開源專案百花齊放的今天，相同問題往往不止一種解決方案。如何才能正確選擇，少挖坑，是件有趣的事情。
需要考量的因素
業務，團隊成員，技術技術選型其實並非一個單純的技術問題，相反技術平臺本身的考量往往是放在最後面的。首先需要考量的是業務本身的特殊性，再結合團隊成員的訴求與能力，最終才在技術方案間做個選擇題。
業務考量
所有脫離業務需求的技術方案，都是耍流氓技術選型是一個小馬過河的故事，廠家宣傳的再怎麼天花亂墜都好，只有真正契合業務上下文的方案才是好的方案，而每個專案都有自己的特殊性，選型者作為掌舵人，需要把專案上下文儘可能瞭解清楚，找出專案成敗最核心的1到2個標準，以此作為基礎來做選擇題。譬如說，創業專案，靈活是明顯的述求，產品推出後必然會面對朝令夕改的需求，如何快速反應是選型的重點。再譬如說，陳年專案效能遇到瓶頸需要重構，再往下挖可能原有系統吞吐量不成問題，但瞬時響應太差，選型時就需要特別注意這個點。以此類推
團隊成員
最終的執行人是成敗的關鍵選擇的方案需要充分考慮團隊成員的技術構成。手頭有幾把槍，什麼槍，未來多長一段時間可以有幾把槍，什麼槍，需要心中有數。另外，方案的選擇需要在核心人員間充分溝通，互通有無，對後期的落地也會更順利些。
技術考量
多對比，多試驗對以上兩個考慮因素有了充分理解後，技術考量反倒是相對容易的事情。多看，多試驗，“按部就班”，即可
儘可能多的羅列出現有解決方案
多數場景下我們所面對的問題，業界都有人面對過，在閉門造車之前，先尋訪下現有的解決方案。
技術前景如何？
技術前景是一個需要優先考量的因素，有些技術看起來性感無比，讓你恨不得立刻使用起來。但可能非常小眾，此時就要非常謹慎，沒準專案還沒有結束，選用的解決方案就太監了。
社群是否足夠活躍？
社群活躍度是技術前景的一部分，需要重點考量。可以通過檢視Github的star數，issue數量，問題修復時長，新版本更新進度；Google Trends；stackoverflow問題數量；文件是否健全；配套的生態是否完整；國內社群論壇版塊等檢視
是否有大廠使用，是否有成熟的案例
站在巨人的肩膀上，自然能看的更遠。（當然，也可能摔的更痛，這就是另一個話題了）。成熟案例也是社群周邊成熟的一個風向標，如今多數團隊都會分享自己的部分解決方案，google之，能從中得到許多資訊。
技術特性
本身的易用性、可維護性、可擴充套件性、學習成本等。初步選定後，多寫點DEMO，多試驗
黑歷史
技術領域不存在可以解決一切問題的銀彈，選型前需要先了解下技術棧的黑歷史。正反用例都需要接收
開源協議約束
開源專案都會有自己的協議規則，決議前需要了解清楚，避免往後的麻煩。
profile
這是個需要特別注意的點，沒有人能保證一個方案萬無一失，一旦出問題，是否有兜底方案，是否能快速strace到問題，profile到熱點顯得尤為重要。
效能
資訊爆炸的今天，軟文無數，壓測還是要自己跑跑。
最後，還有個魔鬼需要面對
新技術之於技術人員，就好比新包包之於妹子，似乎每一個技術人員都對新技術有天然的衝動。
瞧！多麼優雅，多麼性感，馬上用起來！
千萬別！
有時候開發人員自己玩的很high，但專案卻玩死了。這是件很悲哀的事情，我們需要抑制內心深處的魔鬼，技術只有跟業務有機的結合起來，產出所追求的價值，才是有意義的。
拾零散記公眾號
