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 会变成一门更现代、更能打、更有竞争力的语言。
至于今天这次被拒？只不过是通往那个未来的必经之路罢了。