很可惜！PHP True Async RFC 投票未通过

投票未通过

“在 PHP 社区的最新动态中，一项备受期待的变革—— True Async RFC（真正异步RFC）——以遗憾告终。

RFC：https://wiki.php.net/rfc/true_async

2025 年 11 月 20 日启动的投票，仅在短短几天内就显示出压倒性的反对票。

根据 PHP internals 邮件列表的公告和 RFC 投票页面数据，截至目前，已有20位核心开发者参与投票，其中仅有1票赞成、15票反对、4票弃权。

投票截止日期定于12月6日，但以当前2/3多数门槛来看，这项提案几乎注定无法通过。这不仅仅是一次技术提案的落败，更是 PHP 生态在拥抱原生异步时面临的集体阵痛。

在 [🚀 webman技术交流#1] 群早就讨论过，其实这个投票结果在意料之中。Swoole 开源项目创始人韩天峰早就说过，这个 RFC 投票基本是过不了了。

一场雄心勃勃的异步革命

True Async RFC 是由开发者 Edmond Dantes 提出的，旨在为PHP引入原生协程（Coroutines）和 async/await 原语，让并发编程变得像喝水一样自然。

该提案的核心目标非常清晰：让开发者能无缝复用现有的同步代码，只需最小改动即可在协程中运行；同时，确保非协程环境下的代码行为保持不变，前提是正确处理共享可变内存。简单来说，它想让PHP从“同步时代”迈向“异步新时代”，而非强迫开发者从零重写。

提案的关键特性包括：

• Async命名空间：引入spawn()、await()、suspend()等核心函数，以及Coroutine类和Awaitable、FutureLike接口。spawn()可以轻松启动新协程，await()则支持可选取消机制，让I/O操作天生可中断。
• 取消机制：一切操作“可取消设计”，通过CancellationError（继承自Error）实现协作式取消，避免了传统异步的样板代码。
• 调度器与反应器：使用LibUV库的Reactor处理I/O事件，Scheduler管理协程执行。死锁检测和优雅关闭（如gracefulShutdown()）进一步提升了鲁棒性。
• 向后兼容：不改动现有函数签名或SAPI（如FPM、CLI），扩展也能通过C-API轻松集成。

实现上，该 RFC 依赖一个独立的 Reactor 扩展，目标是 PHP 8.6+。它借鉴了 Swoole、AMPHP 和 Go 的经验，但强调“轻量协程”而非重量级goroutine，避免资源浪费。

Edmond Dantes 甚至在GitHub 上提供了原型实现（https://github.com/true-async），展示了一个单例 AuthService 的示例：协程会打破共享状态如 session ID，但SQL查询无需改动——这凸显了提案的哲学：并发问题归责于程序员的责任，而非语言的负担。

从生态影响看，这项RFC本该是福音。它能让PHP在读密集型应用中大放异彩，无需依赖第三方框架如 Swoole 或 ReactPHP，就能实现非阻塞I/O。静态分析工具只需稍作调整，就能检测死锁风险；Opcache 和扩展不受波及，一切看似完美。

投票从期待到失望

投票公告于11月19日由 Edmond Dantes 在 internals 列表发出，1.6 版的一个关键调整是要求所有I/O函数对进程非阻塞（具体行为留给后续RFC）。投票页面独立于主RFC页，以避免混淆，但这反而引发了第一波争议：为什么不直接放主页面？为什么这么仓促？

社区反馈如潮水般涌来。Bob Weinand 质疑投票的突然性，建议取消以便组建工作组，邀请框架代表和库开发者参与——他担心Fiber与协程的分离、Cancellation的Error分类（应为顶级Throwable？）、FutureLike命名等未决问题。Tim Düsterhus指出API违反Throwable策略，如缺少基异常\Async\AsyncException，并批评命名不一致（如gracefulShutdown应为蛇形）。Rob Landers则从Go和AMPHP经验出发，强调共享内存的不可预测性：没有明确挂起点，异步代码仍会乱套。

更深层的分歧在于“设计委员会”的风险。Daniil Gentili批评讨论多为理论和“自行车棚”（bikeshedding），呼吁单一清晰愿景而非人人插手。Deleu担忧异步PHP的采用率低，兼容同步代码至关重要。Jakub Zelenka认为提案解释不足，争议话题太多（如现有同步代码的安全性），建议拆分成小RFC：先非阻塞设置，再I/O钩子。

尽管有支持者，如Michał Marcin Brzuchalski投“是”以示对原生异步的总体拥护，以及Swoole作者 Tianfeng Han 的赞许（他详述 Swoole 用 Boost.Context 实现栈满协程，重用PHP函数，经海量测试可靠），但反对声浪盖过一切。Tianfeng Han还对比了FrankenPHP和Fiber的局限，呼吁语言级异步I/O支持，却未能扭转大局。

最终，投票结果残酷：15:1的反对比，远低于2/3门槛。弃权票反映了犹豫——许多人认可方向，但细节未熟。

PHP异步之路何去何从？

True Async的失败并非终点，而是警钟。它暴露了PHP社区在重大变革前的痛点：缺乏共识、API设计门槛高、向后兼容的紧箍咒。PHP以稳定著称，但这也让创新如履薄冰。Swoole 等框架虽已证明异步可行，却因生态碎片化而难成主流。提案的“可取消设计”虽优雅，但协程与Fiber的互斥（创建一方会抛FiberError）加剧了分裂。

未来，或许该从“小步快跑”入手：先推Reactor扩展，再渐进协程API。社区可借鉴Go的经验，建立专家小组，避免“人人都是架构师”的陷阱。同时，教育开发者处理并发内存（如避免全局状态）至关重要。

很可惜，这次True Async RFC如昙花一现。但正如Edmond Dantes的示例所示，协程能让PHP代码“SQL查询不变，世界多线程”——梦想虽暂搁浅，种子已播下。PHP开发者们，让我们拭目以待下一个黎明。或许在PHP 9.0，它会以更成熟的面貌归来。