PHP 在最近收到了一个可以实现协程的扩展 RFC：Fibers（https://wiki.php.net/rfc/fibers）。
Fibers 从本质上来讲是一个加强的，有栈的生成器，通过 Fibers 可以对整个调用栈代码无侵入式的暂停和恢复执行，再配合用户层面实现 EventLoop 和异步 IO，可以做到非常通俗易懂的，很常规的代码中实现协程，说人话就是最终做到不需要用 yield，不需要第三方扩展，即可实现纯 PHP 的协程，写法上和常规的代码没有区别。
但是这样的一个 RFC，却引起了诸多的争辩，尤其是国内知名的协程扩展 Swoole 的相关人员几乎全投了反对票。当然支持的人也是非常多。
相关讨论见：
https://www.zhihu.com/question/448805077
https://zhuanlan.zhihu.com/p/356942841
https://www.oschina.net/news/133232/php-fiber-proposal
开源中国文章截图
从韩天峰的角度说 PHP 协程要从长计议，fibers 可能只对 amphp 有利（amphp 是基于 yield/Generator 实现的纯 PHP 协程库，fibers rfc 正是该团队提出的），PHP 要出协程要从 EventLoop、内部组件的协程化、整个生态等方方面面全方位考虑。
对于 Fibers 我的看法是这样的：
语言本身应该对特性做出最根本、精简的支持、尽量不做全套（这是库和框架该做的事）。
Fibers 本身已经接受很多意见，把 Fibers 精简为只是一个 Generator 的加强版，虽然目的是为了协程，但这个特性本身只是一个暂停/恢复的生成器，Swoole 本身也可以使用 Fibers，可见近些年的新星 Rust 对异步的支持上也是类似的做法。
如果全方位考虑异步 IO 和协程有两点问题：
实现较难，讨论实现周期会特别长，等真的做出来恐怕已经是 N 年以后的事了，近几年各大语言关于协程特性的发展飞速猛进，所有其它的语言不是有协程就是有多线程，这两个重磅特性使他们在各种场景发挥着价值，而 PHP 还是在做 Web 而且还在流失。PHP 虽然从 7 开始，到 8.0 对执行性能有了很大的突破，但在其它语言的这些进步的特性上其实是微不足道，大量的 PHP 开发人员转移到 Java、Go 已经是不争的事实。如果再等几年，恐怕 PHP 会无力挽回这样的局面。
全方位考虑异步 IO 和协程恐怕会危及 PHP 现有生态，所有语言都害怕生态的这种变化。当 PHP 在语言层面做出巨大的功能性支持和变化时，会让原有的所有生态都考虑这种转变，学习的成本也会很大，会导致原有的优势也丧失殆尽，恐怕反而会加剧 PHP 市场的流失。比如 Java 一些古老的 jdbc 等各种基于多线程组件来看，Java 的协程化进展缓慢。Pecl、D、Python 2 -> 3 等各种语言在版本变化时所做的改变用了多少年才让大家有所适应，甚至是基本被淘汰出了市场。
所以 Fibers 反而是最适合加入进来的，让 PHP 主线就支持 Fibers，让市场的选择去慢慢完善协程的生态。
其实最近这几年 PHP 界对协程的呼声一直很高，网上的各种讨论也早就有，比如 Swoole 扩展本身也对 PHP 的协程发展起到了很好的促进作用。比如在 fibers 之前就已经有一个叫作 fiber 的提案，还有其它的一些实现层出不绝，只不过进展缓慢，最后都被放弃了。好不容易 PHP 有这么一个稳妥的进步，我的意见就是百分之百支持。
截止目前为止，Fibers 赞同票 40 票，反对票 11 票，很大的可能 Fibers 会通过，从而进入 PHP 8.1。
时代的浪潮势不可挡，时代的发展也是各种因素导致，有些人和事促进了时代的发展，当时代发展起来之后这些人和事逐渐消退也是势不可挡，他们的贡献巨大，但更应该拥抱变化。
后续更新：
Fibers 提案已经以 50 比 14 的票数正式通过了投票，可喜可贺。
支持+1