写在前面

PHP 开发者等了二十年。

二十年来，每一次有人问「PHP 能不能优雅地并发」，答案永远是——「装个 Swoole」「用 ReactPHP」「上 AMPHP」。每一个答案都正确，每一个答案都在告诉你同一件事：PHP 语言本身做不到。

直到今天。

一个叫 True Async 的项目，正在试图把这一切改写。不是又一个框架，不是又一个 Composer 包——是一次内核级的手术。目标：PHP 8.6。

这不是「又一种异步方案」。这是 PHP 这门语言，第一次真正意义上把并发能力写进自己的基因。

一、PHP 最大的问题，从来不是「慢」

很多人骂 PHP 慢。但 PHP 真正的问题从来不是 CPU 不够快——是它在「等」 。

传统 PHP-FPM 的工作方式，像一家高档餐厅里每个顾客都配一个专属服务员。服务员下单后，就站在厨房门口干等。菜没做好，他不动；菜做好了，他端上去，然后顾客走人，服务员也被「解雇」。

每个请求独占一个进程，处理完就销毁。 隔离性好，开发简单，调试容易——代价是巨大的资源浪费。

// 传统 PHP-FPM：串行等待
$user = file_get_contents('https://api/user/123');    // 站着等 300ms
$orders = $db->query('SELECT * FROM orders');          // 站着等 150ms
$balance = file_get_contents('https://api/balance');   // 站着等 200ms
// 总耗时：650ms。CPU 空闲，内存空闲，一切都在干等。

三个 I/O 操作，CPU 什么也没干，就在那等着网络包回来、等着数据库返回结果。这不是 PHP 慢，这是 PHP 在浪费生命。

而 True Async 给出的答案简单粗暴：别等了。

// True Async：三个任务同时出发
$page = spawn(fn() => file_get_contents($url));
$rows = spawn(fn() => $pdo->query($sql)->fetchAll());
$stats = spawn(fn() => file_get_contents($api));

// 总耗时：300ms（最慢那个的时间）
 [$html, $data, $meta] = await_all_or_fail( [$page, $rows, $stats], timeout(2000));

代码还是那个代码，味道还是那个味道——只是不等了。

二、True Async 最狠的一刀：砍掉了「函数染色」

如果你写过 JavaScript 或 Python 的 async/await，你一定经历过那个噩梦——

一个函数一旦变成异步，整个调用链都得跟着改。 你加了一个 async，你的调用者就得加 async，调用者的调用者也得加 async……整条链全部「染色」。同步代码和异步代码，活生生被撕成两个世界。

True Async 干的第一件事，就是把这道墙拆了。

没有 async 关键字，没有 await 关键字（是的，连 await 都不需要满天飞）。你写的所有普通函数、所有现有代码，一行不改就能在协程里跑。

file_get_contents() 还是那个 file_get_contents()，fopen() 还是那个 fopen()，mysqli_query() 还是那个 mysqli_query()。唯一的区别是——在协程里，它们自动变成非阻塞的。

「你写的代码看起来还是顺序执行的，但运行时帮你处理了所有的切换。」

这就是 True Async 的「圣杯」：用同步的写法，跑出并发的性能。

已经适配的原生函数超过 70 个——DNS 解析、PDO 数据库、cURL、Socket、文件 I/O、sleep()、exec()……覆盖了一个 Web 应用 90% 以上的 I/O 场景。在协程外，它们的行为和以前完全一样——零破坏性。

三、内核级改造，不是修修补补

True Async 和其他方案的根本区别在哪？

Swoole 是扩展，ReactPHP 是库，AMPHP 是框架——True Async 是内核。

它直接修改了 Zend 引擎、I/O 层、数据库层和 Socket 层。不是一个跑在 PHP 之上的「异步层」，而是PHP 自己变成了异步的。

这意味着什么？

意味着你不需要为了用并发而换框架。Laravel 能用，Symfony 能用，原生 PHP 也能用。项目官方已经提供了 Symfony 适配器和 Laravel 运行时 Spawn。

意味着你不需要学习一套全新的 API 哲学。spawn() 启动协程，await() 等待结果，Scope 管理生命周期——就这么几个概念。

意味着你可以在 FPM 模式下使用它。是的，你没看错——传统 PHP-FPM 也能享受并发。

更狠的是，True Async 还内置了一个纯 C 实现的 HTTP/1.1、HTTP/2、HTTP/3 服务器。不需要 Nginx，不需要 Apache，不需要反向代理——PHP 自己就是一个高性能 Web 服务器。

在 TechEmpower 级别的基准测试中，基于 True Async 的 PHP 异步框架得分甚至超过了部分以高性能著称的框架。在一个 Laravel 的实际测试中，平均延迟从 4000ms 降到了 13ms——30,000% 的提升。

这不是「优化」，这是「换了个活法」。

四、但现实是残酷的

说到这里，你可能已经热血沸腾了。

但我要泼一盆冷水。

True Async 的 RFC 第一次投票，没通过。

2026 年 2 月 16 日，RFC 1.6 版本进入正式投票。结果是不通过。项目作者 EdmondDantes 在 2026 年 7 月的一篇文章里写了一段话，读来令人唏嘘——

「TrueAsync RFC 将在未来一年内或至少在 PHP 8.7 中被投票通过吗？回答：不会。它将不会通过。有 90% 的概率 RFC 不会被接受。 」

原因呢？

「该项目没有支持，甚至连其基本哲学都不被支持。几乎没有 PHP 社区的人理解它的目的是什么……人们会把 TrueAsync 和多线程混淆，或者把 TrueAsync 和彩色函数混淆。这甚至在 PHP 媒体空间的关键人物中也是如此。 」

一个改变 PHP 命运的技术，卡在了「没人理解它」上。

作者自己承认：「在营销方面，我失败了。 」

「本以为人们会喜欢一个经过深思熟虑、连贯的 API……以顺序方式编写代码，却异步运行它。这毕竟是圣杯：'这已经再简单不过了。'但事实证明，实现这个想法是不够的。」

还有第二个问题：代码量太大，没人审。

「使用 C 语言编写的巨大 TrueAsync 代码库会让人望而生畏，因为没有资源来审查它。」

一个改变内核的项目，需要顶级 C 语言和 Zend 引擎专家来 review。这样的人，全世界掰着手指头数得过来。而他们——很忙。

但作者并没有放弃。他说：

「项目将一直执行到版本 1.0.0。这是计划好的，会完成的。」

2026 年 7 月，作者又提交了一个新的 Pre-RFC——不再试图一次性把所有异步能力塞进内核，而是只改引擎，让扩展来实现调度。核心本身没有调度器、没有事件循环、没有 reactor——只做一件事：让 PHP 引擎在并发环境下「行为正确」。

这是一次战略后退，也是一次更聪明的进攻。

五、PHP 8.6 已经埋下了伏笔

值得注意的是，PHP 8.6 已经原生实现了 Polling API（Io\Poll） ——直接暴露 epoll/kqueue，不再依赖 1983 年的 select() 系统调用。

这是 True Async 的「地基」。有了这个，异步 I/O 的底层基建已经就位。

而 True Async 的路线图依然清晰：

• v0.6（2026 年 3 月）：完整的 Async API

• v0.7（2026 年夏季）：线程与稳定化

• v0.9（2026 年 Q4）：框架适配器

• v1.0（2026 年 11 月）：稳定版，目标 PHP 8.6

实验性扩展已经迭代到 v0.9.3（2026 年 8 月 13 日发布）。支持 PHP 8.5+，有 Docker 镜像，有 IDE 助手。

它已经能跑了。 只是还没进内核。

写在最后：PHP 的下一站

PHP 从来不是一门「完美」的语言。它有历史包袱，有设计缺陷，有无数人唱衰。

但 PHP 有一个别人没有的东西——它一直在进化。

从 PHP 4 到 PHP 5，从 PHP 7 的性能飞跃到 PHP 8 的 JIT，从 Fibers 到现在的 True Async——PHP 从来没有停止过把自己变得更强大。

True Async 能不能进 PHP 8.6？不确定。能不能进 PHP 8.7？也不确定。甚至最终会不会以现在这个形态进入内核？都不确定。

但方向已经清晰了。

PHP 正在把「简单」延伸到并发时代。它不想让开发者去学一套全新的异步范式，不想让现有的亿万行代码变成废纸——它想让你用你 already 会的方式，写出更高性能的应用。

「我怀疑以后再也不会有像它这样的东西了。」

这是作者的原话。带着一种悲壮，也带着一种笃定。

也许 True Async 最终没能进内核。也许它以另一种形式重生。也许 PHP 的异步之路还要再走几年。

但那个「PHP 不能并发」的时代，已经结束了。

—— 值得每个 PHP 开发者，保持关注。