（转载）为什么不推荐使用swoole和hyperf官方框架

开篇之前，为了证明自己不是为了黑而黑，先说明对swoole和hyperf的接触

(1).参考swoole捐献列表信息（其他小额的未统计，每年都有捐款）：

200.00    高久峰    希望 swoole 协程客户端生态越来越好    开源中国

(2).我们已经购买swoole商业产品tracker的离线版(目前内网部署)

(3).线上使用hyperf的项目(目前已经停用，更换为Python)+部分论坛项目(正在使用中)

先说下目前swoole和hyperf发展状况：

【一】.swoole

(1).swoole从异步模式到同步协程模式，编码方式及其舒服

(2).基本php官方维护的扩展或函数基本已经全部hook

(3).全面c++后的代码工整规范了很多，阅读比之前容易了

(4).目前4.x还是非常稳定的，bug越来越少

(5).文档大改，舒服多了

(6).生产可用

(7).最新版本的curl_hook是真的curl了,不是phplibrary实现了

(8).swoole商业版加密软件是真好用(扯偏了，不过赞1下，哈哈)

(9).swoole tracker真心不好用，不如zend server，zend-server还便宜

【二】.hyperf

(1).2.0版本相当稳定

(2).越来越多的官方协程客户端支持

(3).phar打包的确舒服

(4).生产可用(请看下面的翻车现场，我司老服务翻车次数有点多)

swoole的发展对于所有phper来说是好事情，因为没有swoole，我们都是在fpm上开发，最多接触下cli，不会花太多时间研究多进程、进程通信、信号管理、同步异步、Yield、Select、Epoll、端口复用、阻塞非阻塞、协程调度之类的技术，这一点我们必须感谢swoole。因此我标题的意思只是不建议使用，学习还是要学习的，学了没有坏处。

对于不推荐使用swoole和官方框架hyperf主要是从技术选型来说的，一个项目选择某项技术要考虑很多因素：例如考虑所采用的技术是否稳定、社区是否活跃、社区的支持程度、定制型、是否官方方案(很重要)。切记，项目特别小或者公司特别大，不要担心，随便用。小项目能用多久还是问题，大公司swoole自己定制修改即可。对于没有技术能力独立维护swoole的开发团队请慎用，毕竟不是PHP官方方案。

现在看看swoole和hyperf目前的问题吧
【一】.swoole

(1).swoole并不是严格意义上的官方扩展，我从3年前就以为swoole是php官方扩展，其实swoole只是官方pecl扩展，真正的官方扩展是php-src中包含由官方在维护的扩展。目前算php官方pecl扩展的有409个，突然想到之前还帮swoole刷pecl排名，差点害了swoole，这里道歉一下。

(2).swoole不太可能也没可能合并到php-src,因为合并到php-src必然是c语言+最小核心，而swoole目前是大量c++，而且太多乱七八糟的功能。为了合并到php-src，swoole团队中的成员独立搞出了swow扩展，这个目前看起来有可能合并到php-src，而且swow的代码及其简洁，是真的骚，我们公司有位同学也在贡献，但是看起来项目不怎么活跃了。有兴趣的可以关注下国外的fiber项目，可能会合并到php-src

(3).swoole有点激进，对于我们开发者来说，我们当然希望全部用最新的php版本，swoole目前开始不再支持 PHP7.1

(4).扩展兼容性，最新swoole使用协程时，无法使用pcntl官方扩展。swoole的出发点很好，但是不支持官方扩展有点…..

(5).Hook只是开始，协程生态道阻且艰。完善协程生态有很多路，一种是和amphp和reactphp一样使用纯php造客户端，在swoole的v4 版本后内置了 Library 模块，所以这个路子+jit是可行的，但是路太远，各种客户端协议维护成本高，一种是要求第三方扩展使用底层提供的socket或者stream来实现客户端，貌似不可行，php本身用户量没有那么大，第三方不太可能为了你专门适配。这种只需要swoole全部hook了zend提供的api，第三方客户端来适配即可，但是我觉得不太可能，这个可以在php-src中看到php官方人员的回复，即使可能对于第三方来说修改很小，对方也不愿意去修改。

(6).swoole官方的运营非常失败，从有赞、Hyperf，Swoole_plus，Swoole微课程，Swoole出版图书来分析。有赞事件我不太清楚真相，swoole如果能再包容点，或许还能帮助swoole推进发展步伐，如今有赞直接上Java，拜拜了您；Hyperf事件中swoole如果能做好library的中立性或许就不会出现现在这种尴尬的状况，swoft、mixphp、easyswoole或许还很积极帮助swoole发展；swoole_plus是swoole的商业化探索，是一个好的出发点，开源没有收益，没有饭吃，哪里有精神来开源，可惜swoole_plus刚出来就是号称“比社区版更稳定”，一瞬间社区版变为“小白鼠版本”。后来讨伐严重了，swoole声称“我们是卖给商业公司帮助社区版踩坑”，你觉得商业版的用户是傻子吗？商业版和社区版唯一的区别只能是功能增强，千万别拿稳定说事；Swoole微课程付费学习swoole，学员在Q群投诉不按照约定进行发布课程，要求退款，结果被踢出群。我也是服了，人家花钱没有买到服务被踢了；Swoole出版图书销售没有问题，只有电子版卖到400还是480，这个金额没问题，后来发现国外卖的比国内还便宜，这不是割韭菜，因为连目录都不给，被喷的太惨了。

(7).协程底层Hook中各种大量的定时器和进程IPC开销，也不算缺点，貌似也只能这样。

(8).核心贡献者不活跃了，韩天峰又开始自己亲自上了，参考github

(9).phpcon之后继续组织好未来开发者大会卖票，来重复讲Hyperf和PHP8特性？最后卖不出去直接免费直播了。。。。

(10).doubaokun作为swoole核心4年开发者，因为代码安全问题和韩天峰产生争执，被剔除开发组，doubaokun担心swoole开源项目的不可控因素创建分支openswoole，早有人质疑热加载的安全性，韩天峰还是不改，是为了推广自己的swoole面板吗？当然doubaokun再拉分支也只能导致社区割裂，swoole都没有多大生态，再拉一个分支何必呢？还是希望双方冷静下，互相理解。具体吃瓜链接Swoole 的管理界面从第三方服务器热加载代码

(11).php8之后的下一代php官方协程的已经是fiber协程扩展方案了，很显然php官方的协程方案生态依然从零开始，swow协程扩展方案虽然还是准备合并到php-src，但是个人觉得希望渺茫，swoole未来或许会边缘化，更多的是提供商业支持。

【二】.Hyperf

(1).Hyperf的作者黄朝辉本身是Swoft团队中的一员，Hyperf和Swoft代码相似度高达百分之80以上，前期的代码直接抄，相关吃瓜和图片链接等下底部加上。

(2).Hyperf的作者没有开源精神，常规操作（修改命名空间、删除注释、删除版权、不注明出处），把Laravel抄的裤衩子都不剩了，作者解释是自己不熟悉mit协议，mit协议不熟悉，难道你不知道什么叫许可文件，版权文件的字面意思，你不是第一天做开源了吧，其成员李铭吸在群中说已经道歉了，目前我没有找到任何道歉文章，如此严重的抄袭，是在哪里道歉的？

(3).Hyperf官方组件删除注释，面对质疑，一名叫李铭吸的作者直接开骂， 虽然后来进行道歉了。面对质疑号称是非官方开发小组成员，难道你们内部没有审核机制？然后各种踢人操作

(4).Hyperf目前的确稳定，刚发布就号称生产验证、生产可用，我们从1.0开始，基本每周都能修复我们部分小bug

(5).Hyperf的用户其实还不如thinkphp，开源中国投票存在大量刷票行为，加了作者的人应该都收到每天的群发消息了，或者Q群各种@刷票，作者微信更是每天自动邀请未加群的人。

(6).Hyperf作者在面对选择框架的时候的回答，“还有其他框架可以选？”请问是谁给你的自信啊，哈哈

(7).Hyperf作者其他的金句自己搜瓜

(8).Hyperf作者最近承认了自己删除别人代码版权和许可证问题，但是认为不是恶意的。好吧我认可，但是你们说已经道歉了，我问在哪里道歉，她说反正又不是向我们道歉。。所以哈哈。。。

(9).Hyperf真的是生产可用吗？官方说自己生产环境在用，那么请问Amqp这么重要的组件，连接池keeplive都没有做好，拿出来的链接都死了，所以发送失败和接收失败。是2.1最新版本啊，幸好我司的老项目影响不大，持续重启。官方现在修复了也是单独发了composer包让我们用。bug位置一键直达 。

(10).奇葩设计，ampq服务端宕机，hyperf消费者进程也挂掉，也就是amqp服务端如果挂掉，你还得重启下hyperf。不过后来看到这不是奇葩设计，只是一个bug，已经修复，但是稳定版2.1依然存在这个bug https://github.com/hyperf/hyperf/issues/3795 hyperf2.2发布修复此问题但是拒绝承认是bug，说这是优化的更好不算bug，评价隐藏我在知乎的评论。

(11).奇葩设计，hyperf接入apollo启动，hyperf每隔一段时间读取最新配置，如果http连接失败，好家伙，整个hyperf服务直接挂掉了，运维只能重启，这是1.x版本的问题，现在2.x不知道有这个问题吗。

(12).奇怪问题，hyperf并发测试下snowflake生成id重复了，1.x版本，后来升级到2.x问题解决了

(13).微服务中分布式事务组件很重要，目前php几乎没有，当然hyperf后期肯定会搞

(14).只要给黄朝辉反馈问题，都是你使用的问题，跟hyperf没有关系，然后说我们内部使用很稳定，那你别修复我们提交的issue试试，那么多人提交了issue才修复，修复了还不承认是bug

(15).Hyperf格局太小，不信你在群里讨论其他框架试试，比如thinkphp，看看黄某人踢不踢你就完了

(15).Hyperf组件问题这么多，何谈企业级框架？企业都在给你踩坑？觉得我黑hyperf的人直接去github看issues就行好吧？尤其这个gotask组件真的是小白鼠版本。

从swoole和hyperf来说，商业化不是问题，成功的开源项目需要商业化支持。但是把用户当作韭菜收割，吃相未免太难看。如果开源夹杂太多的利益和虚荣注定走不远，这才是重中之重。

从Swoole和Hyperf现状来看，如果追求真正的稳定和长期，还是不推荐使用Swoole和Hyperf，当然也包括其他Swoole框架。官方方案fpm+opcache+jit+长连接，或者workerman，稳如老狗，官方方案，有问题自己轻松解决。实在没有办法可以引入第三方语言综合即可。如果你关注PHP官方的协程或者异步方案，可以浏览下Amphp作者推出的Fiber扩展，已经通过rfc，预计在php8.1发布，但是不要对fiber抱太大希望，从整体上来说fiber甚至不如swoole，因为fiber无法兼容已有php生态。

附上各种吃瓜链接：

• 吃瓜链接1
• 吃瓜链接2
• 吃瓜链接3
• 吃瓜链接4
• 吃瓜链接5
• 吃瓜链接6
• 吃瓜链接7
• 吃瓜链接8

总有别人恶意抹黑我是其他swoole框架成员：

(1).Hyperf框架作者李铭西在微信群直接把我当imi框架的人

(2).Imi框架作者在自己群直接说我是es框架的人

(3).Hyperf作者在开源中国直接把我当es框架的人

我活跃在各种swoole群，包括swoole官方群(已经退出，因为不用)，Hyperf官方群(已经退出，作者恶心)，Imi官方群(因为作者当时地域黑骂群成员,所以我退群了,虽然不是我的地域，很反感，另外imi作者在自己QQ群抹黑别人，被自己的人截图，还骂别人是奸细，真的是搞笑，进你群就是支持你的？)，Swoft官方群(一直在，方便吃瓜)，OpenMix(一直在，常规划水群)，还是那句话，不建议用swoole相关框架，狗才站队。

无论如何，swoole都为社区带来了伟大的贡献，也希望在未来能看到swow合并到php-src中，感谢swoole和swow为php社区的贡献，今年swow扩展开始创建rfc，未来或许swow扩展会成为php官方协程方案，理性看待，合理选择适合自己团队的技术栈。

再总结下：

【一】、Swoole虽然有很多自身问题，但是教会了我们phper更多的知识，虽然现在swoole没有那么好，但也是一个好的开始

【二】、PHP市场下滑严重，缺少对标Spring的框架，Hyperf的出现也是有意义的，虽然现在官方组件问题比较多，但是这是正常的，因为团队人少，开发的组件多，框架需要时间来打磨，要想想java spring发展多久了，多给hyperf一点时间。如果你的项目是重要项目，看重稳定性暂时不建议选择hyperf，毕竟宕机重启可能会被你的上级屌。如果是个人项目，技术狂，在企业中有很大话语权，可以直接用hyperf，毕竟自己能抗，自己也有时间来处理这种问题。也希望hyperf能正视这些问题，而不是直接拒绝差评，直接踢人解决问题。

【三】、希望swow扩展早日合并到php-src，也祝愿Hyperf早日成为php届的spring，让php适合的领域越来越广泛，而不是和我们公司一样最终转java了。

本篇文章转载自 高久峰的博客，上面说的事情也都是公开可查的，在此记录一下。基于上述文章，对于 swoole 及其衍生框架个人建议是可以学，但不建议使用于生产环境。

以上。