这是一篇综合类技术选型指南，试图为你提供一份比较通用的技术选型思维框架。当你需要进行技术选型时，可以参照它来设计自己的决策树。这其中你需要考虑的主要维度包括目标产品、目标用户、目标团队和技术本身，下面我将分别细述，并在此基础上介绍一些反模式。
维度
目标产品这是最重要的维度。产品本身的特征将影响技术选型时的很多因素。
短生命周期产品和长生命周期产品
短生命周期的产品通常要求快速起步：门槛低、书写自由、不强制遵循任何最佳实践。当它的使命结束时，代码会被直接抛弃。所以，对于这类产品，“快糙猛”的技术是较好的选择，当然，能做到“快精猛”更佳。
而长生命周期的产品则会强烈要求可维护性，因为它们在很长时间内都是不可报废的。甚至对于一些生命线产品，连重写都会要求在重写期间线上系统平稳过渡，一点点迁移到新技术。
这种要求对团队的工程化能力是个极端的考验。如果没有相应的工程能力，其代价甚至会高于用新技术重新写一个功能相同的系统。
探索型的产品和守成型的产品
探索型产品往往也是短周期产品，但是同时也有自己的特点。它要求快速，但往往同时会要求高质量。探索型的产品如果证明了可行性，那么过渡到长生命周期的可能性很大。
这就要求它最好是一个微内核系统，提前留出一些扩展的空间。当然，设计微内核系统对架构师的能力具有相当的考验，如果没有一个优秀的架构师，建议还是不要刻意做任何预留，优先保障系统的简单性。
除此之外，探索型产品的技术栈必须支持可靠的、自动化的重构。因为探索型产品的迭代速度很快，如果完全靠人工去添加功能并手动重构，那么一旦出现BUG，将给此产品的用户体验带来严重的负面影响。
所以，除非由于人才储备等原因而被迫做出折中，否则探索型产品的技术栈一定要快速而严谨。
当然，“大力出奇迹”定律也是成立的。也就是说，如果你有决心也有力量在将来对这个探索型产品进行彻底的重写，那么采用快糙猛的技术快速把它搭建起来，也未尝不可。如果你的业务确实能如预期般爆发，那么只要把重点放在系统延展性等方面即可；但是如果不能如预期般爆发，可能就会导致维护成本在中期开始飙升，在竞争中处于劣势。这是一种“不成功便成仁”的策略。据我所知某独角兽企业就是在业务起来之后通过巨额投入来偿还技术债的。但这对于CTO的技术直觉是一项极大的考验，不要轻易效仿。
而对守成型产品的选型则会侧重于与现有技术栈的相似程度和无缝整合能力。如果整合时需要借助很多技巧，那么可能你就是在给自己挖坑。
在引入新技术的过程中，要尽可能符合现有的开发流程、基础设施和开发习惯。当然，如果现有的这些已经严重过时，那么应该找新老技术的专家，共同帮你设计一个路线图，让你可以平稳地引入新技术，这份投资绝对值得。如果老技术已经有新版本，则应该优先考虑升级它。不要幻想换个技术栈就能解决一切问题，事实上，它带来的问题往往会更多。
边缘产品和生命线产品
在人员的学习能力和意愿允许的前提下，边缘产品是最佳的试验场，适合探索各种候选技术，试验各种激进方案，积累经验教训。其影响范围可控，即使失控也不会带来太大的损失。当然，即使探索，也应该有计划地探索，不要每个边缘产品都采用不同的技术方案，那样会给人才供应带来巨大的挑战。
而生命线产品则应该稳妥优先，采用保守方案。所以应该优先采用团队内部积累了一定经验或具有稳定的强力外援的技术。
所有的生命线产品几乎必然是长周期产品，所以其可维护性同样是重中之重。
产品维度总结
在目标产品维度上，低价值产品优先考虑门槛低的技术，但是高价值产品应该尽早进行投资性技术积累，优先考虑天花板高的技术，这样才不至于在若干年之后被迫重写。如果工程化能力不足，这种重写往往会成为灾难。
目标用户用户的特点对于技术选型具有显著的影响，甚至可能会导致产品不可用。
浏览器版本
在前端领域，浏览器版本是永远的痛，但这是需要权衡的。高版本浏览器甚至是单一的低版本浏览器会显著节省开发成本，但是可能会损失一些用户。该怎么解决呢？当然不能拍脑袋决定。
如果你们已经有同领域的线上系统，那么应该统计这些线上系统的访问情况，得出一个最准确的、针对目标客户群的统计，然后分析一下不同版本的浏览器有多大价值，有没有可能通过非技术手段让用户使用你们的目标浏览器。即使没有线上系统，也可以随机对目标用户群发一些调查问卷，确定他们的实际使用情况，以及安装新版浏览器的可能性。
下下之策是查一下百度公布的全网浏览器数据，然后说“我们要支持某某浏览器，它还有10%市场占有率呢！”，这是懒。
用户带宽
同样是前端领域，文件的下载体积可能会被一些人当做亮点进行宣传，但是你要清楚，现在已经是4G时代了，更不用说很多企业内部应用都是千兆带宽。就算能比候选技术小k，在4G带宽下（假设现实带宽是2MB/s）也就是毫秒，有谁能感觉到这部分差异？这就是一个明显的“误导读者”的例子。
可访问性
在产品的用户群体中，不但有健康人，还有色盲以及盲人等残疾人。特别是对于面向消费者的产品，尽可能的考虑这些人的需求不但能体现出产品的“人文关怀”，而且也在一定程度上扩大客户群。比如苹果和微软等大公司都把可访问性放在了核心位置。如果你决定要实现可访问性，那么就应该把它作为一项需求，纳入到选型时要考虑的因素中。
之所以要把它纳入到技术选型过程中，是因为添加可访问性支持的代价比较高，而很多第三方库并没有提供这方面的支持。所以应该提早考虑。
国际化
与可访问性相似，国际化也是一个后期添加代价比较高，但很多候选技术却没有提供支持的特性。
如果你的产品在预期生命周期的相当一段时间内需要供多语言用户使用，那么，在初期选型时，就要把候选技术的国际化能力和质量纳入你的主要考量。
访问频度
用户的访问频度对前后端的技术选型都有很大影响。
比如说一个一年只用一次的功能，考虑其性能很可能是没有必要的，在一小时内跑完和在一分钟内跑完往往没有显著的价值差异。但是这两种技术方案却可能有着硬盘占用、编程复杂性、运维复杂性等方面的成本差异。你需要考虑：那种能在一分钟内跑完的技术是否能给你带来足够的价值。
对于前端来说，频繁访问的、面向消费者的应用通常会要求更高的流畅度，那么在技术选型时，就要选择流畅度更高的技术。但是这个流畅度一定要设计一个仿真的场景，亲自验证一下，甚至做一些灰度发布在现实场景下进行验证，而不要只看其