核心模块一个框架最核心的几个部分就是我们前几节课讲到的：HTTP 服务的启动方式、路由、Context、中间件、重启方式，它们的实现非常关键，往往影响到整个框架的表现，也能直接体现出框架作者的开发水平。框架的核心模块就好像是汽车的引擎，一旦核心模块出了问题，或者有隐性的缺陷，后果往往是无法弥补的。理想的核心模块必须要有设计感，有自己的思想，代码质量、性能都不能出问题。

功能完备性

框架最好能尽可能多地提供功能或者规范，比如有自己的日志模块、脚手架、命令行工具，甚至自己的 ORM、缓存等等。

要知道，框架的本质还是在于提高开发效率，在团队中，我们希望不同水平的同学能写出基本一样的代码，那就要靠框架这个顶层设计来规范了。试想一下，如果框架中提供了很方便的参数验证规范，那在开发应用的时候，还有谁愿意走解析和正则匹配来验证参数呢?

在功能完备性的选择上，我们往往会根据之后是否希望自定义需求来确定。这里说的自定义需求，指的是定制自己的日志、ORM 等模块的需求。

框架扩展性

理想的框架，它的扩展性一定要好。框架要做的事情应该是定义模块与模块之间的交互标准，而不应该直接定义模块的具体实现方式。我可以在这个标准上扩展出我需要的功能，这样整个框架才会比较灵活。Web 领域的技术边界在不断扩展，谁也无法保证框架中所用的库，哪怕是最基本的日志库，能永远满足需求。当框架使用者想为应用增加一个功能，或者替换某个第三方库的时候，如果改动的地方非常多，要大动干戈，甚至根本就无法支持替换和增加，那这个框架的扩展性就比较弱了。

框架性能

虽然大部分框架都是封装 net/http，但是封装程度不同以及具体的实现选择不同（使用的路由匹配、上下文机制等），就会有不同的性能表现。我们选择框架之后，最终是要在框架上运行代码的，如果运行效率有指数级别的差距，是不能接受的。参考：https://web-frameworks-benchmark.netlify.app/result

文档完备度及社区活跃度

开源不仅仅是将代码分享出去，同时分享的还有使用文档，官方必须提供足够的介绍资料，包括文档、视频、demo 等。文档和社区是需要不断运营的，因为在使用的过程中，我们一定会遇到各种各样的问题，官方的回复以及一个活跃的社区是保障问题能得到解决的必要条件。

所以当我们选择一个框架的时候，官网、GitHub 的 star、issue 都是很好的衡量标准。当选择框架之后，不妨每天花一点时间在这个项目的官网、GitHub 或者邮件组上，你会得到很多真实信息。

参考: https://github.com/mingrammer/go-web-framework-stars