(转载)为什么不推荐使用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下，哈哈)

##【二】.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造客户端，在 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).php8之后的下一代php很有可能就是php官方协程的探索，目前fiber协程扩展方案已经申请合并到php-src，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作者最近承认了自己删除别人代码版权和许可证问题，但是认为不是恶意的。好吧我认可，但是你们说已经道歉了，我问在哪里道歉，她说反正又不是向我们道歉。。所以哈哈。。。

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

从Swoole和Hyperf现状来看，如果追求真正的稳定和长期，还是不推荐使用Swoole和Hyperf，当然也包括其他Swoole框架。官方方案fpm+opcache+jit+长连接，或者workerman，稳如老狗，官方方案，有问题自己轻松解决。实在没有办法可以引入第三方语言综合即可。如果你关注PHP官方的协程或者异步方案，可以浏览下Amphp作者推出的Fiber扩展，已经进入rfc阶段。

附上各种吃瓜链接：

吃瓜链接1

吃瓜链接2

吃瓜链接3

吃瓜链接4

吃瓜链接5

吃瓜链接6

吃瓜链接7

总有别人恶意抹黑我是其他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官方协程方案，理性看待，合理选择适合自己团队的技术栈。

本文转载不需要征求作者同意。