这两天，又一全栈式 Swoole 协程框架面世了 - hyperf，实现思路是我内心点了赞同的，就集成现有 PHP 生态优质组件到 Swoole 的协程中来。
有人想到，为什么不是 Swoole 集成到 Web 框架中，当然已经有案例了，如果是老项目这么做是可以通过常驻内存提升性能的，并且利用到 Swoole 一些特性。
但是天花板也正是传统 Web 框架的限制，它们运行组件不是为常驻内存和协程而设计的，所以99.9%无法透明支持 Swoole 的，这是历史使然。
php-fpm 是多进程模型打天下的，Web 服务器是 Nginx 多，PHP 从不用考虑太多，憋说话，加机器就能解决的问题算问题吗。
现在科技进步了，都会举一反三了，眼界也必须要高呀，要省机器，要高性能，要云原生，矛盾就这么出现了。
所有基于 Swoole 的开发框架，上来必先普及一番 Swoole 协程的注意事项，这些注意事项都是在 Swoole 官方 wiki 上都有的，但依然穿插在框架文档的各个地方，
大家都这样做，厌恶感莫名就上来了，为什么 Swoole 官方 wiki 上有，你的开发框架文档上还要再拷贝一份呢，其实在我看来，这不会是简单的拷贝，
起码是框架作者深谙 Swoole 协程用法，拷贝顺带自己的理解敲上去的，因为不写的话，肯定大伙儿一用都是坑，到时候先吐槽，啥玩意儿，还不如我裸写的呢。
是的，当你把 Swoole 官方 wiki 上的特性、注意事项都了然于胸的时候，裸写是最爽的，性能最高，但是咋维护呀，这必须解决呀。
那么些个框架都出来好久了，用用看？要是写个小开源衍生作品，用就用呗，挂就挂了，不兼容就不兼容了，存档就存档了，不管那么多。
谁还没裸写过，这时候你理直气壮的创造了基于 Swoole 的第 109 个框架 swoole-micro .
Link：https://www.cnblogs.com/farwish/p/11062359.html