开发环境：Windows服务器版 VScode Apache MySQL5.7 PHP7 – PHP8

基于ThinkPHP Layui 完美契合，在开发上采用最精简最高效的做法去完成业务系统的需求，是一款优秀的中后台极速开发解决方案。

开发初衷

---

1. SAPHP框架的开发，主要是为了减少在自己开发过程中的频繁造轮子，并且SAPHP框架主张简单就是高效的原则，所以最简单的东西才是效率最高的，可能你的应用场景很复杂，但是SAPHP足够应付！
2. 在最开始接触互联网的时候，都是用一些开源的CMS系统制作自己的网站，后期因为扩展和二次开发的问题，导致觉得很多东西并不是那么简单易用，比如后台的很多JS代码封装的不是很好，而且界面可操作性很差，所以自己开发这款框架封装了很多常用的特性，足以满足日常后台的开发需要，在使用的过程中你会发现，SAPHP框架里面用的最多的是属性而不是对象，一是为了在书写HTML标签的时候方便。二是为了和layui本身区分开！这样让你更容易在这个上面进行扩展！
3. 系统默认从基础控制器继承了增删改查操作。但这种方式并不适合大多数硬性的应用场景和逻辑需求，你可能在后期需要摈弃大多数利用了一键CURD的方法进行重载函数，虽然SAPHP框架里面也有，但框架的设计初衷是为了在易用性和操作性上折中找一个方案来做，当前基于第一个版本的SAPHP框架在这方面的表现还不是特别好。但随着应用场景检验和优化，本框架会逐步的进行完善和提高性能！
4. 在市面上目前的开源极速开发框架的学习成本略高，想搞一个学习成本极低，但性能不低的框架（CMS系统）！
5. 想着开发一款底层设计配置和应用分开的系统，这样对于很多小白用户不会在项目已经上线运行中的时候，误操作系统的配置导致数据丢失，错乱的问题。比如有些字段需要手动在数据库进行修改。

侧重点

---

• SAPHP的架构和开发更倾向于内容管理系统[CMS]的方向，当然你也可以当中API系统使用
• 系统默认的缓存机制为redis缓存，所以请确保安装redis扩展和服务器[摒弃操蛋的file缓存吧]
• 如果你只是需要一个极简的API管理系统，那么建议你删除不需要的模块和菜单项！
• 会侧重于SEO优化、客户管理、流量管理、蜘蛛池、区块链以及采集方面的应用！！！
• 坚持偏向于社区版开源的方向，主要由社区共同的爱好者免费开发维护插件！！！
• SAPHP已经上线插件市场🔧，适用于中小型企业采购付费商业版插件的使用！！
• 本框架特别适合个人开发者和小型创业公司，找一款真正适合自己的框架不容易，所以先来试试SAPHP吧！

框架优势

---

• 代码量最少最精简、逻辑简单清晰
• 参考官方文档，只需会PHP JS 开箱即用
• 界面基于ant design设计 [可操作性强]
• 控制器与栏目管理双鉴权，满足日常大部分需求
• 前端JavaScript鉴权，后端AUTH类鉴权，减少请求
• 封装常用组件和快捷属性，小白即可快速二次开发
• 支持全文索引XS/ElasticSearch轻松支持PB级数据
• 通用型thinkPHP插件开发架构，可轻松迁移其他插件
• 代码安全质量高，修复大部分低危、高危代码漏洞
• 高占比AJAX数据调用，响应速度可媲美前后端分离

集成功能

---

• [√] API模块 支持token鉴权，支持细分规则
• [√] CMS模块 系统内容CMS模块，搭配模板，开箱即用
• [√] 用户管理 用户是系统操作者，该功能主要完成系统用户配置。
• [√] 公司管理 设置公司常用信息，前端标签调用
• [√] 部门管理 配置系统组织机构（部门、小组），树结构展现支持数据权限。
• [√] 岗位管理 配置系统用户所属担任职务。
• [√] 菜单管理 配置系统菜单，操作权限，按钮、栏目等权限标识等。
• [√] 角色管理 角色菜单权限分配、设置角色按机构进行数据范围权限划分。
• [√] 插件管理 可开发定制属于自己的插件，可安装升级社区插件！！！
• [√] 导航管理 支持导航定制，小分类导航配置适合SEO
• [√] 内容管理 系统默认模型数据已完成后端数据录入，可快速二次开发！！！！
• [√] 广告管理 运营必选功能，获取广告代码自动校验过期时间
• [√] 数据字典 对系统中经常使用的一些较为固定的数据进行维护，并使用自定义标签交互
• [√] 操作日志 用户后台操作日志，全局异常、SQL注入等记录
• [√] TAG过滤 支持违规词、敏感词配置
• [√] 短信平台 支持阿里云、腾讯云短信发送
• [√] 附件上传 支持FTP、阿里云、腾讯云OSS附件上传
• [√] 全文检索 支持XunSearch、ElasticSearch集群PB级全文检索
• [ ] 服务监控 服务监控：监视当前系统CPU、内存、磁盘、堆栈等相关信息。
• [ ] 定时任务 在线（添加、修改、删除)任务调度包含执行结果日志。
• [ ] 代码生成 前后端代码的生成（php、html、layui、sql）支持一键CRUD 。

由于工作需要，这些年来也接触了不少的开发框架，Golang的开发框架比较多，不过基本都是Web”框架”为主。这里稍微打了个引号，因为大部分”框架”从设计和功能定位上来讲，充其量都只能算是一个组件，需要项目使用的话得自己四处再去找找其他的组件，或者自己造轮子。如果用于Web开发，这些”框架”的Web开发能力均已完备，无太大差别，且均是自标准库net/http.Server的二次封装。由于框架众多，这里笔者只选择了几个曾做过技术选型评估、较为熟悉，且目前比较流行和典型的Golang”框架”，从适用于业务项目开发框架的角度，做一个简单的横向比较，以便大家在项目框架选型时做个参考。

评估指标

横向比较

• 以下部分对比参数涉及评分的部分，满分总共按照10分为标准。
• 如果标记为”-“的部分，表示不支持或者需要引入第三方插件支持。
• 以下特性如果官网提供文档则直接提供文档地址，找不到文档但是笔者知道有就会简单标注。
• 各个”框架”功能特性实现不同，在文档、功能、易用性上存在较大差异，各位朋友可自行查阅链接。

 

	GoFrame	Beego	Iris	Gin
比较版本	v1.15.2	v1.12.3	v12.0.2	v1.6.3
项目类型	开源（国内）	开源（国内）	开源（海外）	开源（海外）
开源协议	MIT	Apache-2	BSD-3-Clause	MIT
框架类型	模块化框架	Web框架	Web”框架”	Web”框架”
基本介绍	工程完备、简单易用，模块化、高质量、高性能、企业级开发框架。	最简单易用的企业级Go应用开发框架。	目前发展最快的Go Web框架。提供完整的MVC功能并且面向未来。	一个Go语言写的HTTP Web框架。它提供了Martini风格的API并有更好的性能。
项目地址	github.com/gogf/gf	github.com/beego/beego	github.com/kataras/iris	github.com/gin-gonic/gin
官网地址	goframe.org	beego.me	iris-go.com	gin-gonic.com
模块化设计	是	–	–	–
模块完善度	10	6	4	2
使用易用性	9	9	9	10
文档完善度	10	8	6	4
工程化完备	10	8	5	1
社区活跃	9	10	9	10
开发模式	模块引入、三层架构、MVC	MVC	MVC	–
工程规范	分层设计、对象设计	项目结构	–	–
开发工具链	gf工具链	bee工具链	–	–
Web: 性能测试	8	8	8	9
Web: HTTPS	HTTPS & TLS	支持	CustomHttpConfiguration	支持
Web: HTTP2	–	–	支持	支持
Web: WebSocket	WebSocket服务	有	有	–
Web: 分组路由	路由注册-分组路由	Namespace	GroupingRoutes	有
Web: 路由冲突处理	有	–	有	–
Web: 域名支持	域名绑定	–	–	–
Web: 文件服务	静态文件服务	静态文件处理	ServingStaticFiles	有
Web: 多端口/实例	多端口监听、多实例监听	–	RunMultipleServiceUsingIris	–
Web: 优雅重启/关闭	平滑重启特性	热升级	GracefulShutdownOrRestart	GracefulRestartOrStop
ORM	ORM文档	ORM文档	–	–
Session	Session	Session	有	–
I18N支持	I18N	I18N	Localization	–
模板引擎	模板引擎	View设计	TemplateRendering	HtmlRendering
配置管理	配置管理	参数配置	–	CustomHttpConfig
日志组件	日志组件	Logging	–	–
数据校验	数据校验	表单数据验证	–	CustomValidators
缓存管理	缓存管理	Cache	–	–
资源打包	资源管理	bee工具bale命令	–	–
链路跟踪	链路跟踪	–	–	–
测试框架	单元测试	–	Testing	Testing
突出优点	goframe主要以工程化和企业级方向为主，特别是模块化设计和工程化设计思想非常棒。针对业务项目而言，提供了开发规范、项目规范、命名规范、设计模式、开发工具链、丰富的模块、高质量代码和文档，社区活跃。作者也是资深的PHP开发者，PHP转Go的小伙伴会倍感亲切。	beego开源的比较早，最早的一款功能比较全面的Golang开发框架，一直在Golang领域有着比较大的影响力，作者谢大多年组织着国内影响力比较大GopherCN活动。beego有着比较丰富的开发模块、开箱即用，提供了基于MVC设计模式的项目结构、开发工具链，主要定位为Web开发，当然也可以用于非Web项目开发。	iris主要侧重于Web开发，提供了Web开发的一系列功能组件，基于MVC开发模式。iris这一年发展比较快，从一个Web Server的组件，也慢慢朝着beego的设计方向努力。	gin专注于轻量级的Web Server，比较简单，易于理解，路由和中间件设计不错，可以看做替代标准库net/http.Server的路由加强版web server。献给爱造轮子的朋友们。
突出缺点	开源时间较晚，推广过于佛系，目前主要面向国内用户，未推广海外。	起步较早，自谢大创业后，近几年发展较慢。非模块化设计，对第三方重量级模块依赖较多。	号称性能最强，结果平平。非模块化设计。最近两年开始朝beego方向发展，但整体框架能力还不完备，需要加油。	功能简单易用，既是优点，也是缺点。

经验分享

不同的需求场景，存在不同的选择。选择适合的工具，解决适合的问题。

开源不存在孰好孰坏之分，开源作者能够本着开源精神给大家分享技术成果用以学习和使用，这本身就是一件非常不易并且值得称道的事情。

最后，笔者在这里跟大家分享一下自己所在团队的情况，以及在Golang技术栈转型过程中所走的弯路，希望能在框架选型这一环节，能给大家作一定参考。

团队最初痛点

团队转型Golang技术栈的一些背景。主要几点：

1. 团队后端最初的主要技术栈为PHP，由于业务发展需要，进行微服务改造。第一版微服务采用了PHP+JsonRpc的通信方式。
2. 随着项目增多，公司也组件了自己的DevOps团队，底层部署转向了Docker+Kubernetes容器架构，并且引入了Golang技术栈。
3. 由于一些痛点，通过一段时间对PHP和Golang的比较，团队决定快速转型Golang技术栈，主要痛点如下：
   1. PHP项目在业务复杂后、项目中后期的开发和维护成本整体偏高。主要原因还是其过高的灵活性，非结构化的变量设计，参差不齐的开发人员素质。
   2. 上云容器化部署后，PHP的DevOps效率太低。复杂的Composer版本管理，超大的Docker镜像大小，都影响着DevOps的效率。相比较而言，Golang效率极其高效。
   3. JsonRpc通信协议设计下，接口的扩展性和灵活性很高，但服务之间很难快速确定接口的输入与输出定义，只能根据文档和示例进行对接和维护。由于代码和文档分离，大部分场景下接口文档维护往往滞后于接口变化。随着服务的不断增加，非结构化的通信协议管理使得服务接口的开发和维护成本进一步提高。
   4. JsonRpc的通信协议本质基于HTTP1.x+Json，执行效率过低，算不上真正的微服务通信协议，很难对接上主流的服务治理框架。相比较基于HTTP2.x的gRPC协议有着成熟微服务开发框架和服务治理解决方案。
   5. 业务梳理的考量，PHP到Golang技术栈的迁移，其实也是一次技术重构的契机，在技术重构的过程中也重新梳理业务系统设计，偿还技术债务。

进一步的痛点

Golang确实足够简单，相比较其他的解释类开发语言，没有过多的语法糖和语言特性，因此团队上手很快，并快速完成了一部分业务系统的技术重构。但随之而来的是更加严重的痛点。主要几点：

1. 轮子过多：Golang实在太简单了，以至于我们的团队成员爆发了压抑许久的闷骚劲，充分发挥”造后不管”的造轮精神，开发/封装了许多大大小小的轮子。这些轮子均能满足最基本的功能，例如：日志、配置、缓存等等。但轮子并不是实现一个基础功能的半成品就了事，需要保证功能性、稳定性、扩展性和可维护性，要能结合更多生产实践验证，更需要能够长期维护、持续进行迭代改进。否则，就是一堆大小不一的成人玩具。造轮一时爽，维护火葬场。直到现在，我们还在为分散在100多个Golang项目中的数十个成人玩具做大统一的事情痛苦不已。当然，这个问题也跟组织架构和团队管理也有很大关系。
2. 不成体系：
   1. 我们坚信一个package只做一件事情，并且特地使用单仓库包的形式进行包管理，相当于每个package都是独立维护的git仓库。其实单仓库包和package设计并不存在必要性，反而独立的单仓库包提高了组件和框架的维护成本。
   2. 这种单仓库包设计难以形成技术体系，在团队技术管理上，难以形成统一的技术框架。单仓包显得很孤立，而一个技术体系的建立除了需要制定规范和标准，更需要技术框架来准确落地。一个成体系的、统一的技术框架，至少涉及到数十个基础技术组件，不可能完全孤立设计。每一个package的基础功能实现都很简单，但是如何能够统一组织在一起却不是一件简单的事情，这需要团队的技术管理者需要有一定的技术底蕴、格局和前瞻性，而不是和普通开发者那样眼界只能局限于package本身。
   3. 这种孤立的单仓库包设计，对于业务项目的规范化约束不强，每一个组件都可以独立替换，也至于痛点1的问题越发严重（连日志组件都好几套，虽然都满足基本的日志规范设计）。最终，我们最初引以为傲的单仓库包设计，最终变成了一堆散沙。例如，就连需要增加标准化的链路跟踪功能，由于单仓库包过于散乱和不统一，使得推进改进成本极其高昂。
   4. 除了使得技术体系难以建立，技术规范难以准确落地之外，每个组件的易用性也设计得较差。举个简单例子，我们的日志组件、缓存组件、数据库组件、HTTP/gRPC Server组件都需要对接配置管理功能，单仓包需要保证低耦合设计，因此开发者在使用的时候需要先手动读取配置、并转换为目标配置对象、并注入到对应的组件初始化方法中，随后才能将该对象运用到业务逻辑中，若干个业务项目均是重复此步骤。其实goframe在这块的易用性设计就挺不错，每个包当然是独立设计的，在统一的技术框架体系下，再独立提供一个耦合的单例模块将常用的对象进行单例化封装，自动实现配置读取、配置对象转换、配置对象注入及组件对象初始化，开发者仅需要调用一个单例方法即可。而这个常用单例模块，成为了我们技术框架体系的一部分，极大地提高了业务项目的开发和维护效率。
3. 版本不一致：在业务项目不断增多之后，轮子版本不一致性也越来越明显。什么是版本不一致？举个例子。我们有个轮子叫做httpClient，总共发布了10来个版本；我们总共有100多个Golang项目，几乎每个版本都在使用。我们提交了一个bug fix，却难以让所有项目都能更新。对其他的轮子也是类似的情况，况且我们也有数十个各种轮子，被各个项目独立使用中。

经过反思总结，总结了以下几点：

1. 团队需要一个统一的技术框架，而不是东拼西凑的一堆单仓库包。
2. 我们只需要维护一个框架的版本，而不是维护数十个单仓库包的版本。
3. 框架的组件必须模块化、低耦合设计，保证内部组件也可以独立引用。
4. 核心组件严格禁止单仓库包设计，并且必须由框架统一维护。

最终的抉择

走过这么多弯路之后，我们决心建立一套成体系的Golang开发框架。除了要求团队能够快速学习，维护成本低，并且我们最主要的诉求，是核心组件不能是半成品，框架必须是上过大规模生产验证的，稳定和成熟的。随着，我们重新对行业中流行的技术框架做了技术评估，包括上面说的那些框架。原本的初衷是想将内部的各个轮子统一做一个成体系的框架，在开源项目中找一些有价值的参考。

后来找到了goframe，仔细评估和学习了框架设计，发现框架设计思想和我们的经验总结如出一则！

这里不得不提一件尴尬的事情。其实最开始转Golang之前（2019年中旬）也做过一些调研，那时goframe版本还不高，并且我们负责评估的团队成员有一种先入为主的思想，看到模块和文档这么多，感觉应该挺复杂，性能应该不高，于是没怎么看就PASS。后来选择一些看起来简单的开源轮子自己做了些二次封装。

这次经过一段时间的仔细调研和源码学习，得出一个结论，goframe框架的框架架构、模块化和工程化设计思想非常棒，执行效率很高，模块不仅丰富，而且质量之高，令人惊叹至极！相比较我们之前写的那些半成品轮子，简直就是小巫见大巫。团队踩了一年多的坑，才发现团队确实需要一个统一的技术框架而不是一堆不成体系的轮子，其实人家早已给了一条明光大道，并且一直在前面默默努力。

经过团队内部的调研和讨论，我们决定使用goframe逐步重构我们的业务项目。由于goframe是模块化设计的，因此我们也可以对一些模块做必要的替换。重构过程比较顺利，基础技术框架的重构并不会对业务逻辑造成什么影响，反而通过goframe的工程化思想和很棒的开发工具链，在统一技术框架后，极大地提高了项目的开发和维护效率，使得团队可以专心于业务开发，部门也陆续有了更多的产出。目前我们已经有大部门业务项目专向了goframe。平台每日流量千万级别。

最后，感谢开源作者们的默默贡献！我们也在努力推动团队秉着来源社区，回馈社区的思想，未来也会更多参与社区贡献。