

Swoole 团队的 TypePHP 项目或许能成为新 PHP 核心及其运行时子集的基础。即便不是 TypePHP,其他类似的项目也能做到。用 PHP 编写 PHP,或者至少使用能够构建 PHP 的 PHP 子集,这种想法并非新鲜事。Phalcon 团队多年前就得出了同样的结论,事实证明他们完全正确。
“PHP 已死”或“PHP 衰落”的论调在技术圈里早已不是新鲜事。然而,现实是 PHP 依然驱动着互联网上庞大比例的 Web 流量。PHP 的真正困境不在于它不够好用,而在于它的演进机制被锁死在了一个过时的架构假设里:核心用 C 写,应用用 PHP 写。
这种两层割裂导致了极高的门槛。想给 PHP 内核添加一个特性,或者实现极致的性能优化,开发者必须深入 Zend Engine 的 C 语言底层。能做这件事的人屈指可数,这极大地限制了语言的自我进化速度。
那么,什么能让 PHP 重获新生?答案或许藏在一个并不新鲜的构想里:用 PHP 编写 PHP,或者至少使用能够构建 PHP 的 PHP 子集。
“用 PHP 编写 PHP 运行时” 的想法并非今天才有。多年前,Phalcon 团队就得出了同样的结论,事实证明他们完全正确。
作为最早追求极致性能 PHP 框架 Phalcon 最初是用纯 C 语言编写的 PHP 扩展。虽然性能逆天,但开发与维护成本极其高昂,调试困难,新增功能周期极长。为了打破这个僵局,他们发明了 Zephir——一种介于 C 和 PHP 之间的领域特定语言(DSL)。它允许开发者用类似 PHP 的语法编写代码,然后编译成 C 扩展。
Phalcon 团队的核心洞察在于:PHP 生态需要高性能,但不能以牺牲 PHP 开发者的心智模型为代价。 既然 C 语言门槛太高,那就创造一个 PHP 的子集来桥接。这一实践证明了“用类 PHP 语言来构建 PHP 运行时组件”在工程上是完全可行的,只是当时受限于技术生态,Zephir 最终未能走得更远。
多年后的今天,Swoole 公司的 TypePHP 项目(原 PHP Native AOT)让这一构想迎来了真正的落地契机。TypePHP 不仅仅是一个编译器,它有望成为新 PHP 核心及其运行时子集的基础。 TypePHP 的核心能力在于 AOT(提前编译)技术。它将 PHP 源码直接编译为原生二进制可执行文件,彻底跳过 Zend 虚拟机的解释执行和 JIT 的运行时编译。在计算密集型场景下,性能提升惊人,目标直指 Go 和 Rust。
Swoole-Compiler 将提供 PHP Native AOT 编译器,支持将 PHP 代码编译为可执行文件,运算性能提高 150 倍
更重要的是,TypePHP 的实现策略非常聪明。它并没有另起炉灶重新实现一套 PHP,而是直接复用 ZendPHP 底层库,通过 PHPX 库作为兼容层,在 ABI 层面与原生 PHP 保持互通。这意味着它既能享受原生机器码的执行效率,又能完整复用 Composer 生态和现有的 PHP 扩展。
即便最终不是 TypePHP 独占鳌头,其他类似的项目也能做到这一点。因为 TypePHP 走通的技术路线——保留 PHP 外观、收敛部分动态特性、通过静态类型推断直接生成机器码——指明了 PHP 走向系统级语言的可行路径。
为什么“用 PHP 子集构建运行时”对 PHP 的复兴如此重要?
因为它打破了 C 语言的垄断,将语言的演进权交还给了广大的 PHP 开发者。如果运行时的核心逻辑可以用类型化的 PHP 子集来描述和迭代,那么社区贡献者就不再需要成为 C 语言和 Zend API 专家。语言特性的演进、性能的调优将进入一个正向循环。
当然,天下没有免费的午餐。TypePHP 这类 AOT 方案必须对 PHP 的动态特性做一定妥协。诸如 $$ 可变变量、extract()、生成器等高度依赖运行时确定的特性将无法支持。这意味着 PHP 将分裂出一个更为严谨的“静态子集”。但这并非倒退,而是顺应时代的需求——在需要极致灵活性的传统 Web 场景,依然使用 Zend VM;在需要高并发、高性能、云原生部署的场景,则转向 Swoole 协程或 TypePHP AOT。
PHP 的重获新生,绝不是靠某一个框架或某一个 Web 服务器来完成的。它是一场多运行时并行的现代化演进:Symfony Runtime 提供了运行时抽象,FrankenPHP 带来了现代化的部署外壳,Swoole 解决了高并发难题,而 TypePHP 则补齐了原生性能与源码保护的拼图。
从 Phalcon 的 Zephir 到 Swoole 的 TypePHP,历史跨越了十年,但技术理想一脉相承。当 PHP 终于能够用自身(或其子集)来重塑自己的骨骼与肌肉时,这门古老的语言才真正迎来了它的第二次青春。