PHP True Async RFC 被拒——原生异步离 PHP 还有多远？

PHP 社区最近经历了一个出人意料的时刻：备受期待的 True Async RFC 进入投票阶段后，遭遇了滑铁卢。这个原本旨在将真正的异步能力引入 PHP 核心的提案，目前几乎铁定会失败——9票反对，1票弃权。

对于一个等了好几年的特性，这结果确实让人失望。不过，就像大多数技术争议一样，事情远不止表面看起来那么简单。这些反对票不是在否定 async 本身，而是在质疑"应该用什么方式把 async 加进来"。

这次投票失败不是故事的终点，它只是 PHP 通往原生异步编程这条漫长曲折道路上的又一个路标。

原文链接 PHP True Async RFC 被拒——原生异步离 PHP 还有多远？

为什么 PHP 开发者这么渴望 Async？

在现代后端开发领域，"异步"早就不是什么新鲜事了。Node.js、Go、Python 的 asyncio、Rust 的 async/await——异步编程几乎成了每门主流语言的标配。它撑起了高并发服务器、实时应用，还有各种 IO 密集型系统。

反观 PHP，基本还停留在同步阻塞的老路子上。来一个请求，跑完，结束，进程重置——简单是简单，但局限性也很明显。当然了，社区也搞出了不少优秀的异步方案，像 Swoole、ReactPHP、Amp 这些，但说到底它们都是外部库，不是语言自带的能力。

对很多 PHP 开发者来说，原生异步支持就是语言进化过程中最大的那块缺失拼图。

所以当 True Async RFC 宣布要把真正的异步——协程、事件循环、非阻塞 IO——直接整合进 PHP 核心时，大家的期待值一下子拉满了。有些人甚至开始畅想，这会不会彻底改写 PHP 的定位：从一门传统 Web 语言，变成高并发、长连接服务领域的有力玩家。

也正因如此，很多人觉得这次投票会顺利通过。

现实却给了大家一记闷棍。

为什么被拒了？

如果只看数字，9票反对看起来像是彻底失败了。但你越深入阅读讨论，就会越觉得意外：大多数核心开发者强烈支持给 PHP 加 async——他们只是不认同当前的 API 设计。

反对意见主要集中在几个方面。

命名和异常层级不符合规范

举个例子：

RFC 里引入了一个 DeadlockException
但按照 PHP 的官方规则，这应该叫 DeadlockError

听起来是小事？确实不大。但问题是，核心 API 一旦发布就几乎改不了了。命名标准定得严格，不是没道理的。

API 命名风格前后不一

有些函数用了驼峰命名，可 PHP 的标准是蛇形命名：

gracefulShutdown() → 按规矩应该写成 graceful_shutdown()

类似的不一致在好几个方法和辅助函数里都能看到。

这对普通开发者来说可能无关紧要，但对语言核心设计而言，一致性是大事。

调度器设计的哲学争议

RFC 采用了全局调度器的模式，但有开发者觉得这个设计：

暴露了太多内部实现细节
容易被滥用
理解成本高
可能会踩进其他语言早期 async 实现踩过的坑

有位核心开发者投反对票时说得很直白：

"我不是反对 async 本身——我反对的是这套 API 设计。它还没成熟。"

说白了就是：方向没问题，但具体怎么做还得再琢磨琢磨。

这算失败吗？

乍一看，RFC 被否确实像一次挫折。PHP 的 async 之路走得太慢了，每隔几年希望起来又落下。开发者难免会想：这是不是又一次"PHP 放弃 async"？

但如果从语言治理的角度看，这其实是件好事。

异步编程是把双刃剑：

用好了能大幅提升性能
用不好就引入一堆复杂度
烂 API 会制造回调地狱
调试难度直线上升
错误处理模型可能变得一团糟

PHP 一向把简单清晰摆在第一位。要是草率塞进一个不成熟的 async 实现，对语言的伤害可能比好处还大。

从这个角度说，这些反对票反映的是谨慎，不是排斥。是对语言未来负责任的态度。

不过，True Async 技术上其实挺能打

被否的只是这个 RFC，不是整个 True Async 项目。

项目本身其实已经走得挺远了：

有个能跑的 alpha 版本
基于 libUV 构建
用 Fibers（协程）处理非阻塞执行
不少内置函数在 async 环境下能自动 yield
TCP/UDP/SSL 网络 API 正在开发
最近的 v0.4.0 版本在性能和内存处理上有明显提升

总结一下就是：技术底子打得挺扎实，就是还没成熟到能进 PHP 核心的程度。

那未来怎么办？

虽然这次投票没过，但 PHP 的 async 前景其实没那么糟。

我觉得可以这么走：

重新设计 API，贴合 PHP 的风格

PHP 一贯的调性是：

够简单
够一致
职责分得清楚

下一版 RFC 得在命名规范、异常层级这些地方下功夫，该藏的底层细节就得藏起来。

分步走，别想一口吃成胖子

可以这样分阶段来：

先把调度器标准化
把事件循环敲死
逐步加入协程 API
内置函数慢慢改造成 async 版本

这样风险小，推广起来也容易。

让大家多用用实验版本

True Async 现在就能跑了。多让开发者试试，能暴露出问题在哪，也能为下一版 RFC 积累更多实战数据。

对 PHP 来说，问题不是"要不要 Async"，而是"怎么搞"

要不要给 PHP 加 async？这事儿其实已经没什么可争的了。现代 Web 架构的要求、并发场景的需求、生态的期待，都在朝一个方向指。

Async 是大势所趋。不跟上就意味着掉队。

这次 RFC 被否，不代表 PHP 要放弃 async。恰恰相反，它说明社区想把这事做对——宁可慢点、稳点，也不能砸了语言的招牌。

就我个人来说，我挺乐观的。Async 不会明天就来，过程肯定也不轻松。但它终究会来，而且大概率会是个打磨得很精致、设计得很合理、测试得很充分的版本。

到那时候，PHP 会变成一门更现代、更能打、更有竞争力的语言。

至于今天这次被拒？只不过是通往那个未来的必经之路罢了。