技术人一般都喜欢研究技术，但是如果你问他一般技术选型到底怎么做，估计他一下子懵掉了。因为一般来说，技术人可能更关注于学习什么新技术，反而更少去了解怎么选择一种合适的技术手段去解决业务问题。因为平时日常工作也需要涉及到这块领域，因此心里一直想想总结一下，毕竟作为一个十几年的老司机，在做技术选型的时候如果完全都是随心所欲的话，那就真的太水了吧。 首先，技术选型它会涉及到方方面面的因素，例如市场上的人员招聘难度、技术组件的社区活跃度、文档丰富程度、具体落地案例、后期运维复杂度、人员学习成本等等不一而足。这里我就开始讲一下我对一个系统的技术选型的一些个人拙见吧，也权当为自己做个总结给到以后参考吧。

社区活跃度高，才不断有人提issue，不断有人commit，这个产品才能健康茁壮的“成长”。一般来说，主要看以下四个指标：

大家有兴趣可以浏览一下Apache项目列表： www.apache.org/index.html#…

我相信任何人也不想当白老鼠吧，特别如果是针对一些更重视成熟方案是否曾经落过地的行业，例如如银行业。

我们在做技术选型或者针对厂商产品选型的时候，要注意奥卡姆剃刀，千万别好高骛远想着要上什么“高大上”的解决方案，看起来多厉害啊；而且要适度的考虑到运维成本，这里的成本包括学习成本、日常运维的时间成本及相应的技术人员储备成本。特别如果对于一些刚创业或者技术团队规模不大的公司，哪里能找到那么多的“全能人”，就算找到凭什么人家要选择你？这样的话带来的人员连续性风险就很高。 笔者曾经所参与的一个项目，单单数据库中间件就有6种，这代表需要懂这6种数据库的人才，但这种人才很难找啊。怎么办？办法不外乎三个：

首先我们要定义或明确公司或团队的技术栈，在这个基础之上，我们需要考虑的是团队的接受程度和能力水平了。如果你的团队是用JAVA的，而导入的框架却是.net的话，那估计就真的是要全部重新学习了。因此在选型时有几个建议：