技术选型是企业项目研发中少不了的一个环节，大部分情况下企业都是优先采用开源免费的技术框架。

有实力的企业在选定技术框架后可能还会做一定的改造优化，以更匹配自己的应用场景，而大部分中小型企业则更多是对技术框架的应用。

所以对中小型企业来说，一个技术框架的选择至关重要，因为在不具备改造开源框架能力的情况下，如果选择了不合适企业实际情况的技术框架，可能解决不了问题，还会带来新的问题。

那么如何选择一款既适合自己的团队又能解决当下面临的问题，不急，我们且往下看。

到底怎么选？1、确定问题核心

这一点，也是我们进行技术选型的动机和出发点，所以很关键，很多情况下我们解决不了问题的原因是不知道问题的根在哪，技术选型也是一样，必须搞清楚引入这一个技术或组件要解决的核心问题是什么，确定自己的问题场景，越具体越好。不能为了用而用。

大部分情况下，每引入一个新的技术组件，在解决现有问题的同时可能会带来新的问题.。所以在确定现有代码、技术组件经过转换思路、变通实现也确实无法解决面临的问题时，再考虑引入新的技术框架。

2、列出技术框架清单

基于第一点分析出的核心问题场景，列出可以解决问题的相关技术框架，一般来说每个问题场景的解决方案都不止一种，这个过程可以输出到文档也可以存在于自己的脑子里。

这里有一个问题就是列表中的技术框架都从哪来，我个人的来源主要是这么几个途径：书籍视频、技术博客，搜索引擎，技术社群，github、gitee代码仓库。不管是平时积累还是现查，途径大致就这么多。

这里多说一点，平时看到一些好的解决方案或技术，要注意积累，可能当下用不到，但至少在脑子里留个印象，记住关键词和核心应用场景，记不住就弄个笔记，当有一天碰到具体问题的时候，在进行具体研究。

3、评估学习成本

有了上面的技术框架清单，下面就需要结合各种情况进行筛选，选出最合适自己或企业的技术，首先就是学习成本的评估。我们需要考虑团队内部的可接受能力和学习能力，不能盲目选择。

1）尽量选择与公司当前使用的主语言一致的技术框架，如公司使用的Java，而找的技术框架是golang语言实现，而公司如果没有专门的golang开发工程师或团队，那么如果使用该解决方案，就需要额外学习golang。

2）文档是否完善，非常重要，除非你愿意直接啃着源码学习，完善的文档可大大提升学习效率

3）网上是否有较多的相关学习资料或技术博客，官方文档更多是技术本身的使用说明，而缺乏实际场景的应用和问题解决方案，所以网上的学习资料和问答有助于我们在使用过程中快速解决和定位问题。

4、评估使用成本

1）与现有系统结合时，所需要的改造成本，一般来说，新项目情况会好一些，主要是历史项目或已经有大量功能开发完成的项目，如果接入这样的技术框架，是否改动足够小。如果动静太大，就需要再斟酌斟酌。

2）投入生产时需要的运行环境或者说物理机配置，比如预算仅仅是两台服务器，而框架官方建议五台集群起，这就是一种使用成本。

5、社区活跃度

社区活跃度决定了一个技术能走多远，也决定了使用过程出现问题能不能得到及时响应，又或者出现BUG能不能及时得到修复。看一个技术的社区活跃度可从以下几方面观察。

1）看github、gitee上的star、fork数，一般来说，能过千的都还可以考虑

2）看issue是否能及时得到解决

3）看版本迭代速度和代码提交历史是否较为频繁，这个频繁说的是至少近2、3个月内有提交记录或版本发布。而不是提交记录或最后一个版本还停留在几年前。

4）搜索框架，是否有一定量的博客或技术问答帖，能搜到说明使用的人多。

6、技术维护团队

1）尽量选择背后有团队支撑的技术框架，当然不乏有个人维护的很优秀的项目，但是长远来看，团队的更加有保障，这个道理相信大家都懂。

但是不是说个人的开源项目就不能使用了，当然可以使用，前提是假如有一天作者不维护了，那么你具有二次改造的能力，又或者你就没有改造的需求，现有功能完全可以满足使用。这种情况下，使用个人的开源项目也无妨。

2）上面说了在团队与个人之间，优先选择团队，那么在团队与团队之间同样优先选择有大企业或知名的开源组织的开源项目。

拿企业来说阿里开源的相对于其他中小企业的开源项目来说，阿里的开源项目肯定更有保障，Apache相比其他组织也更容易让使用者信任。

7、行业内是否主流

主流意味着用的企业多，会的人多，生产环境下的问题解决方案也自热就多，企业内部人员流动是常态，人多有利于企业降低招聘成本和内部人才梯队的延续，也可以降低学习成本。解决方案多能减少因技术障碍带来的开发成本。

如果选择太偏门的技术，一方面出现问题没有太多的解决方案可以参考，另一方面市面上对应的求职者也少，招进来内部培训也可以，那是不是又增加了一定的学习成本。

8、避免盲目追求主流

纳尼？这个不是跟上面是矛盾的吗？不，一点都不矛盾，上面说的是尽量使用主流，来降低团队人员流动带来的成本，但主流不代表你就能驾驭的了，这里我们对自己团队的能力要有清晰的认识，驾驭不好只能带来线上事故，因此对于技术实力一般的企业来说，在主流和熟悉之间，还是应当选择熟悉，毕竟拿的住，保证项目能稳定运行是根本。

9、尝鲜需谨慎

技术领域每天都会产生很多新的技术，新的解决方案，作为技术人员的我们应时常保持一颗学习的心态，初现的新技术作为知识拓展，增长见识是可以的，但要直接应用到项目中还需谨慎，因为社区、文档可能并不完善，存在一定的学习成本，另一方面还未经过大规模生产环境检验，可能存在未知的缺陷，后期出现莫名奇妙的问题，遭罪的就是你和你的团队。

10、场景测试

最后最后，以上综合评估完成后，一定要做的就是进行场景测试，拿具体的技术应用到自己的业务场景，写几个Case进行测试，各方面判断是否能够解决问题，最终选取符合公司情况的技术框架即可。

在没做场景测试之前，切不可直接大规模直接应用到项目中，除非所选技术在别的项目已经使用验证过，有真实的生产实践经验，不然单靠文档或一些资料得到的仅仅是直观感受而已，具体合不合适，还得真实的Coding一把才知道。

总结

以上综合起来就能保证所选的技术万无一失吗？并不能，但是可以大大降低出错的概率，至少眼下来看是合适的。

技术选型其实也是一种权衡与取舍，不可能面面俱到，所以进行技术选型时，我们应该清晰的认识到

技术选型是企业项目研发中少不了的一个环节，大部分情况下企业都是优先采用开源免费的技术框架。

有实力的企业在选定技术框架后可能还会做一定的改造优化，以更匹配自己的应用场景，而大部分中小型企业则更多是对技术框架的应用。

所以对中小型企业来说，一个技术框架的选择至关重要，因为在不具备改造开源框架能力的情况下，如果选择了不合适企业实际情况的技术框架，可能解决不了问题，还会带来新的问题。

那么如何选择一款既适合自己的团队又能解决当下面临的问题，不急，我们且往下看。

到底怎么选？1、确定问题核心

这一点，也是我们进行技术选型的动机和出发点，所以很关键，很多情况下我们解决不了问题的原因是不知道问题的根在哪，技术选型也是一样，必须搞清楚引入这一个技术或组件要解决的核心问题是什么，确定自己的问题场景，越具体越好。不能为了用而用。

大部分情况下，每引入一个新的技术组件，在解决现有问题的同时可能会带来新的问题.。所以在确定现有代码、技术组件经过转换思路、变通实现也确实无法解决面临的问题时，再考虑引入新的技术框架。

2、列出技术框架清单

基于第一点分析出的核心问题场景，列出可以解决问题的相关技术框架，一般来说每个问题场景的解决方案都不止一种，这个过程可以输出到文档也可以存在于自己的脑子里。

这里有一个问题就是列表中的技术框架都从哪来，我个人的来源主要是这么几个途径：书籍视频、技术博客，搜索引擎，技术社群，github、gitee代码仓库。不管是平时积累还是现查，途径大致就这么多。

这里多说一点，平时看到一些好的解决方案或技术，要注意积累，可能当下用不到，但至少在脑子里留个印象，记住关键词和核心应用场景，记不住就弄个笔记，当有一天碰到具体问题的时候，在进行具体研究。

3、评估学习成本

有了上面的技术框架清单，下面就需要结合各种情况进行筛选，选出最合适自己或企业的技术，首先就是学习成本的评估。我们需要考虑团队内部的可接受能力和学习能力，不能盲目选择。

1）尽量选择与公司当前使用的主语言一致的技术框架，如公司使用的Java，而找的技术框架是golang语言实现，而公司如果没有专门的golang开发工程师或团队，那么如果使用该解决方案，就需要额外学习golang。

2）文档是否完善，非常重要，除非你愿意直接啃着源码学习，完善的文档可大大提升学习效率

3）网上是否有较多的相关学习资料或技术博客，官方文档更多是技术本身的使用说明，而缺乏实际场景的应用和问题解决方案，所以网上的学习资料和问答有助于我们在使用过程中快速解决和定位问题。

4、评估使用成本

1）与现有系统结合时，所需要的改造成本，一般来说，新项目情况会好一些，主要是历史项目或已经有大量功能开发完成的项目，如果接入这样的技术框架，是否改动足够小。如果动静太大，就需要再斟酌斟酌。

2）投入生产时需要的运行环境或者说物理机配置，比如预算仅仅是两台服务器，而框架官方建议五台集群起，这就是一种使用成本。

5、社区活跃度

社区活跃度决定了一个技术能走多远，也决定了使用过程出现问题能不能得到及时响应，又或者出现BUG能不能及时得到修复。看一个技术的社区活跃度可从以下几方面观察。

1）看github、gitee上的star、fork数，一般来说，能过千的都还可以考虑

2）看issue是否能及时得到解决

3）看版本迭代速度和代码提交历史是否较为频繁，这个频繁说的是至少近2、3个月内有提交记录或版本发布。而不是提交记录或最后一个版本还停留在几年前。

4）搜索框架，是否有一定量的博客或技术问答帖，能搜到说明使用的人多。

6、技术维护团队

1）尽量选择背后有团队支撑的技术框架，当然不乏有个人维护的很优秀的项目，但是长远来看，团队的更加有保障，这个道理相信大家都懂。

但是不是说个人的开源项目就不能使用了，当然可以使用，前提是假如有一天作者不维护了，那么你具有二次改造的能力，又或者你就没有改造的需求，现有功能完全可以满足使用。这种情况下，使用个人的开源项目也无妨。

2）上面说了在团队与个人之间，优先选择团队，那么在团队与团队之间同样优先选择有大企业或知名的开源组织的开源项目。

拿企业来说阿里开源的相对于其他中小企业的开源项目来说，阿里的开源项目肯定更有保障，Apache相比其他组织也更容易让使用者信任。

7、行业内是否主流

主流意味着用的企业多，会的人多，生产环境下的问题解决方案也自热就多，企业内部人员流动是常态，人多有利于企业降低招聘成本和内部人才梯队的延续，也可以降低学习成本。解决方案多能减少因技术障碍带来的开发成本。

如果选择太偏门的技术，一方面出现问题没有太多的解决方案可以参考，另一方面市面上对应的求职者也少，招进来内部培训也可以，那是不是又增加了一定的学习成本。

8、避免盲目追求主流

纳尼？这个不是跟上面是矛盾的吗？不，一点都不矛盾，上面说的是尽量使用主流，来降低团队人员流动带来的成本，但主流不代表你就能驾驭的了，这里我们对自己团队的能力要有清晰的认识，驾驭不好只能带来线上事故，因此对于技术实力一般的企业来说，在主流和熟悉之间，还是应当选择熟悉，毕竟拿的住，保证项目能稳定运行是根本。

9、尝鲜需谨慎

技术领域每天都会产生很多新的技术，新的解决方案，作为技术人员的我们应时常保持一颗学习的心态，初现的新技术作为知识拓展，增长见识是可以的，但要直接应用到项目中还需谨慎，因为社区、文档可能并不完善，存在一定的学习成本，另一方面还未经过大规模生产环境检验，可能存在未知的缺陷，后期出现莫名奇妙的问题，遭罪的就是你和你的团队。

10、场景测试

最后最后，以上综合评估完成后，一定要做的就是进行场景测试，拿具体的技术应用到自己的业务场景，写几个Case进行测试，各方面判断是否能够解决问题，最终选取符合公司情况的技术框架即可。

在没做场景测试之前，切不可直接大规模直接应用到项目中，除非所选技术在别的项目已经使用验证过，有真实的生产实践经验，不然单靠文档或一些资料得到的仅仅是直观感受而已，具体合不合适，还得真实的Coding一把才知道。

总结

以上综合起来就能保证所选的技术万无一失吗？并不能，但是可以大大降低出错的概率，至少眼下来看是合适的。

技术选型其实也是一种权衡与取舍，不可能面面俱到，所以进行技术选型时，我们应该清晰的认识到