PHP 终于可以“编译自己”了？Swoole AOT 自举背后的野心、边界与下一条路

PHP 写了三十多年 Web，似乎早已被安排好了命运：源码放到服务器，PHP-FPM 接住请求，Zend Engine 把代码编译成 Opcode，再由虚拟机执行。

它可以支撑电商、支付、内容平台，也可以借助 Swoole 跑常驻进程和协程服务。但在人们的固有印象里，PHP 终究还是一门“部署源码、依赖解释器”的脚本语言。至于把代码编译成原生二进制、制造自己的编译器、像 Go 和 Rust 那样完成自举，那似乎是另一个世界的故事。

现在，这条边界开始松动了。

2026 年，Swoole 发布了新一代 AOT 编译器。它可以把 PHP 源码离线翻译成 C++，再交给 GCC、Clang 或 MSVC 编译为 x86-64、ARM64 原生机器码，最终生成 Linux、macOS 或 Windows 下的可执行文件和动态库。官方文档同时给出了 PHP 源码入口 bin/compiler.php 与编译后的 swoole_compiler，背后指向一个更有象征意义的能力：用 PHP 编写的编译器，可以参与编译它自己。

按照编译器工程里的通常定义，这就是官方所说的“自举”。至于它和 Go、Rust 的语言工具链自举是不是一回事，答案是否定的，后面还要继续拆开。

但先别急着宣布 PHP 已经变成了 Go，也别把“生成二进制”自动等同于“彻底摆脱 Zend Engine”。Swoole AOT 真正有价值的地方，恰恰不在宣传口号，而在它暴露出的一条新路线：

PHP 不再只能作为被运行的业务脚本，它开始能够参与制造自己的原生工具。

这件事值得兴奋，也必须冷静看待。

先说清楚：这不是 Swoole 扩展的一次普通升级

很多人看到“Swoole AOT”，第一反应可能是：Swoole 扩展又增加了一个编译参数？

不是。

这里讨论的是 Swoole Compiler 4.0，也就是官方目前以 typephp 仓库发布的 PHP AOT 编译器产品，而不是我们熟悉的 swoole-src 扩展增加了一个新 Hook。它和 Swoole 协程、HTTP Server 可以结合，但两者不是同一个层面的东西：

• Swoole 扩展主要改变 PHP 的 I/O、并发和常驻进程模型；
• Swoole AOT 主要改变 PHP 代码从源码到机器码的构建与交付方式。

截至 2026 年 7 月，官方安装页仍指向 v0.1.0，而 GitHub Releases 已经发布 v0.2.3。这个版本差异本身也说明：它目前仍处在快速迭代的预览阶段，而不是可以无脑替换生产 PHP-FPM 的成熟基础设施。官方安装文档列出的构建条件也不轻：PHP 8.4 ZTS、Embed SAPI、PHPX、Composer 依赖、GCC 9 以上，以及 GMP、MPFR 等库。

所以，理解它的第一步不是问“快了多少倍”，而是先看懂它到底做了什么。

从 PHP 源码到机器码，中间发生了什么

传统 PHP 的主路径大致是：

PHP 源码
  → 词法与语法分析
  → AST
  → Opcode
  → ZendVM 解释执行

启用 OPcache 后，前面的解析和 Opcode 编译结果可以被缓存，避免每次请求重新处理源码。但缓存的仍然是 Opcode，真正执行时依旧要经过 ZendVM。

Swoole AOT 走的是另一条路：

根据官方执行过程文档，编译过程可以拆成四步：

1. 扫描 PHP、C、C++ 等项目文件，收集类、函数、常量和依赖关系；
2. 使用 PHP Parser 生成 AST，再把每个节点转换为 C++；
3. 调用平台上的 C++ 编译器生成目标文件；
4. 将目标文件与 PHPX 等运行库链接为二进制或动态库。

最终产物不是 PHP Opcode，也不是某种跨平台字节码，而是 CPU 可以直接执行的机器指令。这意味着它天然具有平台属性：Linux 的 ELF 不能直接拿到 Windows 运行，x86-64 产物也不会自动变成 ARM64 程序。

更重要的是，Swoole AOT 并非把所有 PHP 语义都粗暴翻译成同一种东西。它实际运行在一个混合环境里。

当编译器能够确定变量类型、函数目标和对象布局时，就可以生成直接的 C++ 运算或函数调用；调用 json_encode()、preg_match()、PDO 等 PHP 内置能力时，仍然可能通过 Zend API 进入原有 C 扩展；部分动态加载可以交给 ZendVM，另一些过于动态的语法则会在编译期直接被拒绝。

换句话说，Swoole AOT 不是抛弃整个 PHP 生态重新造一门语言，而是在 PHP 的动态世界上方，铺设一条尽量静态化的高速通道。

所谓“自举”，到底自举了什么

编译器自举有一个著名的鸡生蛋问题。

假设我们用 PHP 写了一个 PHP 编译器：

compiler.php：读取 PHP 源码，生成 C++，再调用系统编译器

那么第一次运行 compiler.php 时，仍然需要一个已有的 PHP 解释器。它读取编译器源码，生成第一代原生编译器：

已有 PHP 解释器
  → 运行 compiler.php
  → 生成第一代 swoole_compiler

第一代编译器产生后，再让它读取自己的 PHP 源码：

第一代 swoole_compiler
  → 编译 compiler.php
  → 生成第二代 swoole_compiler

如果第二代编译器能够继续正确编译自己，输出也具备预期的语义一致性，那么这个工具链便形成了自举闭环。

它代表的不是一句“我们也有二进制了”，而是编译器已经具备处理真实大型 PHP 工程的能力。一个能编译自己的编译器，至少要面对：

• 大量类、函数、接口和命名空间；
• 文件扫描与 Composer 依赖；
• AST 遍历、符号表和类型推断；
• 字符串、数组、对象和异常；
• C++ 代码生成、并行构建和链接；
• 缓存、命令行参数与跨平台差异。

所以，自举常被视为编译器工程的“成人礼”。它说明这个编译器不再只能编译 Hello World 或几个算法 Demo，而是开始具备承载自身复杂度的能力。

但必须把边界说清楚。

目前 Swoole AOT 的公开仓库主要提供二进制发行包、文档和示例，编译器仍是商业软件，完整源码并未公开。官方文档展示了 php bin/compiler.php、./bin/compiler.php 和 ./swoole_compiler 等入口，这能说明工具链的自托管形态，却不等于社区已经从公开源码独立复现、审计了完整自举过程。

因此，现阶段更准确的说法是：

就目前公开材料而言，Swoole AOT 所说的自举发生在商业编译器产品层面，而不是 PHP 官方语言实现完成了自举。

这两个概念不能混为一谈。

它和 Go、Rust 的自举，有什么联系和区别

Swoole AOT、Go 和 Rust 的共同点，是它们都在回答同一个问题：一门语言能否用自己的能力，制造下一代语言工具？

但三者所处的位置完全不同。

Go：官方编译器与运行时的整体迁移

Go 早期的编译器和运行时包含 C 实现。到了 Go 1.5，官方宣布编译器和运行时主要改由 Go 与少量汇编实现，C 编译器不再是构建 Go 发行版的必要组成部分。Go 1.5 的官方说明也明确提到：既然编译器已经用 Go 编写，从源码构建新版 Go 时，就必须先准备一个可工作的旧版 Go 工具链。

它的基本链路是：

旧版 Go 编译器
  → 编译新版 Go 编译器与运行时
  → 得到新版 Go 工具链

这是官方语言实现层面的自举。编译器、运行时和发行构建流程都属于 Go 项目本身。

Rust：用上一阶段 rustc 构建下一阶段 rustc

Rust 的自举更加显式。按照 Rust Compiler Development Guide 的描述，构建系统会先获取一个已有的 Beta rustc 作为 Stage 0，再用它构建当前源码中的编译器，随后进入 Stage 1、Stage 2 等阶段。

Stage 0：已有的 Beta rustc
  → Stage 1：当前源码编译出的 rustc
  → Stage 2：由新 rustc 再次构建的工具链与标准库

这套过程不只是“Rust 能编译 Rust 文件”，还涉及编译器、标准库、目标平台组件和一致性验证。Rust 依旧使用 LLVM 等由其他语言实现的底层基础设施，所以“语言自举”从来不等于整个软件栈里一行 C/C++ 都没有。

Swoole AOT：在 PHP 官方实现之外搭建新编译链

Swoole AOT 不属于 PHP 官方 Zend Engine 的下一代构建系统。PHP 官方发行版不会因为它的出现，就改用 swoole_compiler 编译 php-src。

它更像是在现有 PHP 旁边搭了一座桥：

• 前端理解 PHP 语法和 AST；
• 中间层进行类型推断并生成 C++；
• 后端借助 GCC、Clang 或 MSVC 产生机器码；
• 运行时通过 PHPX、Zend API 和 Embed SAPI 继续复用 PHP 生态。

三者的联系是“用本语言参与制造本语言的工具”；真正的区别则是：Go 与 Rust 在重建自己的官方语言基础设施，Swoole AOT 在 PHP 官方基础设施之外，为 PHP 增加一种新的工程形态。

AOT、OPcache 和 JIT，根本不是一回事

只要谈到 PHP 编译，就绕不开 OPcache 和 JIT。三者都可能减少解释开销，但发生的时间、保存的产物和适用场景完全不同。

OPcache：不再重复解析和编译源码

PHP 官方对 OPcache 的定义很直接：把预编译的脚本字节码存进共享内存，避免每次请求重新加载和解析脚本。PHP 官方文档源码中的关键词是 precompiled script bytecode，也就是预编译脚本字节码。

第一次：PHP 源码 → Opcode → ZendVM
后续请求：OPcache 中的 Opcode → ZendVM

它省掉的是反复解析、编译 PHP 源码的成本，没有取消 ZendVM 的 Opcode 执行循环。

JIT：程序运行时编译热点

PHP JIT 建立在 OPcache 之上。程序先进入原有执行链，运行时再把值得优化的热点路径编译为机器码。它适合循环、数值计算等 CPU 热点，却很难让等待 MySQL、Redis 和 HTTP RPC 的业务代码凭空快十倍。

JIT 的关键是“Just In Time”：机器码在运行期间产生。

AOT：部署前完成编译

AOT 的关键是“Ahead Of Time”：在程序运行之前生成机器码。

构建阶段：PHP → C++ → 机器码
运行阶段：直接加载编译产物

一句话概括：

OPcache 是“不重复编译”，JIT 是“运行时挑热点编译”，AOT 是“运行前尽可能编译完”。

实战：把一段 PHP 编译成原生程序

Hello World 能证明编译器会工作，却无法解释 AOT 为什么值得存在。我们用一个更适合观察原生整数运算的例子：统计指定范围内的质数。

<?php
declare(strict_types=1);

use native_types;

function isPrime(int $number): bool
{
    if ($number < 2) {
        return false;
    }

    if ($number === 2) {
        return true;
    }

    if (($number % 2) === 0) {
        return false;
    }

    for (
        $divisor = 3;
        $divisor * $divisor <= $number;
        $divisor += 2
    ) {
        if (($number % $divisor) === 0) {
            return false;
        }
    }

    return true;
}

function countPrimes(int $limit): int
{
    $count = 0;

    for ($number = 2; $number <= $limit; $number++) {
        if (isPrime($number)) {
            $count++;
        }
    }

    return $count;
}

function main(int $argc, array $argv): void
{
    $limit = 1000000;

    if ($argc > 1) {
        $limit = intval($argv[1]);
    }

    if ($limit < 2) {
        echo "limit must be greater than or equal to 2\n";
        return;
    }

    $begin = microtime(true);
    $count = countPrimes($limit);
    $elapsed = microtime(true) - $begin;

    printf(
        "primes <= %d: %d, elapsed: %.6f seconds\n",
        $limit,
        $count,
        $elapsed
    );
}

将文件保存为 prime.php，然后编译：

./swoole_compiler prime.php -O2 -o prime

运行生成的程序：

./prime 1000000

这段代码有几个关键点。

main() 取代游离代码

普通 PHP 文件可以在顶层直接写：

echo "hello";

但当前 AOT 编译器要求可编译代码进入函数，不能依赖 PHP 模板式的游离代码。二进制模式会把 main() 作为明确入口，这一点更像 C++、Go 和 Rust 的可执行程序。

use native_types 不是装饰

use native_types 是 Swoole AOT 复用 PHP use 语法定义的专有编译指令，不是普通的命名空间导入。把同一文件直接交给 ZendPHP 语法检查时，它可能提示“非复合名称的 use 没有效果”；交给 AOT 编译器时，它才具有原生类型优化语义。

启用该指令后，明确声明的 int、float、bool 可以映射到更接近 C++ 原生类型的表示。isPrime() 和 countPrimes() 的热点主要是整数比较、取模、递增和函数调用，编译器有机会：

• 消除部分 zval 装箱和类型检查；
• 把用户函数调用编译为直接的 Native Call；
• 让 C++ 编译器执行内联、常量传播和循环优化；
• 把变量尽可能放入寄存器，而不是反复经过 ZendVM。

这也是为什么数值循环比数据库 CRUD 更容易体现 AOT 的收益。

PHP 内置函数仍可能走 Zend API

代码里的 intval()、microtime() 和 printf() 并不会因为 AOT 就自动变成编译器内置指令。它们可能继续通过 Zend API 调用原有 C 实现，并在边界上进行参数装箱。

但这不是问题。真正的热点在 countPrimes() 的大循环里，输入解析与结果输出只执行少量几次。AOT 的工程价值，本来就不是把每一行 PHP 都变成纯 C++，而是让高频路径尽可能原生化。

-O2 优化的是什么

-O2 不只是一个“跑快点”的按钮。Swoole AOT 先生成 C++，随后把优化级别交给 C++ 编译器。函数内联、无用代码消除、寄存器分配等能力，最终由成熟的原生编译后端完成。

需要提醒的是：这段代码用于解释编译模型，不代表文章宣称了一个固定加速倍数。真实结果必须在相同机器、相同输入、相同构建参数下，对 ZendPHP、JIT 和 AOT 分别测试。脱离工作负载谈“快一百倍”，通常只是把一个算法基准偷换成整个 PHP 生态。

为什么很多“灵活的 PHP”到了 AOT 会报错

PHP 的强大，很大程度来自运行时动态性。变量可以变型，函数名可以放在字符串里，类可以自动加载，局部变量甚至能在运行时凭空生成。

例如：

<?php

$handler = 'sendEmail';
$handler($payload);

$name = 'result';
$$name = 'ok';

$value = '42';
$value = new stdClass();

extract($config);

ZendVM 可以等程序真正运行到这里，再决定 $handler 指向谁、$$name 要创建哪个变量、$value 当前是什么类型。

但 AOT 必须在运行之前回答这些问题：

• 我要生成哪个 C++ 函数调用？
• 这个变量需要多少内存？
• 它应该使用整数寄存器、对象指针还是 zval？
• 这个对象的方法表在什么位置？
• 编译器能否证明调用目标不会变化？

如果答案只能在运行时出现，编译器就无法安全地产生确定的原生代码。

更适合 AOT 的写法，是把动态规则改成显式结构：

<?php
declare(strict_types=1);

final class Message
{
    public function __construct(
        public string $content
    ) {
    }
}

function sendEmail(Message $message): void
{
    echo "email: " . $message->content . "\n";
}

function sendSms(Message $message): void
{
    echo "sms: " . $message->content . "\n";
}

function dispatch(string $handler, Message $message): void
{
    switch ($handler) {
        case 'email':
            sendEmail($message);
            break;

        case 'sms':
            sendSms($message);
            break;

        default:
            throw new InvalidArgumentException('unknown handler');
    }
}

function main(): void
{
    $message = new Message('hello AOT');
    dispatch('email', $message);
}

这不意味着以后写 PHP 必须到处堆 switch。真正的原则是：让依赖、类型和调用目标尽可能显式。

根据当前兼容性文档，可变变量、extract()、生成器、部分动态引用、变量类型反复变化、游离代码等能力存在限制；对象属性和继承赋值也比 ZendPHP 更严格。对于依赖反射、动态代理、魔术方法和运行时容器的框架，不能因为“语法看上去是 PHP”就假定它可以原样编译。

这也是 AOT 对 PHP 最深层的改变：

过去，动态性主要支付运行时性能和可维护性成本；进入 AOT 后，它还要支付无法静态分析、无法编译和无法优化的成本。

对 PHP 开发者而言，真正会改变什么

强类型不再只是 IDE 提示

过去我们给参数、属性和返回值加类型，主要是为了静态分析、IDE 补全、运行时校验和团队协作。

在 AOT 里，类型开始直接参与机器码生成。它会影响：

• 变量能否使用原生 C++ 类型；
• 是否需要 zval 装箱与拆箱；
• 函数调用能否变成 Native Call；
• 方法是否有机会去虚拟化；
• 对象属性能否按固定偏移访问；
• 编译器是否需要退回动态调用。

这意味着 PHPStan、Psalm、严格类型、只读对象、DTO 和明确接口，不再只是“代码洁癖”，而可能成为 AOT 性能与兼容性的前置条件。

编译错误会进入日常工作流

传统 PHP 项目经常把许多问题留到运行时。AOT 会把一部分错误提前到构建阶段：

Composer 安装
  → 静态分析
  → AOT 兼容性检查
  → C++ 代码生成
  → 原生编译与链接
  → 自动化测试
  → 按平台发布

PHP 开发者将开始遇到此前相对陌生的概念：

• 目标架构；
• 动态库与静态库；
• ABI；
• 链接错误；
• Debug Symbol；
• GDB；
• Sanitizer；
• C++ 编译器优化级别。

这不是坏事，却意味着构建复杂度真实增加了。过去上传一份 PHP 源码就能部署，未来可能要为 Linux x86-64、Linux ARM64、Windows 和 macOS 分别维护构建流水线。

二进制交付会成为新选择

对普通互联网 Web 项目来说，隐藏 PHP 源码可能不是核心诉求；但对私有化部署、商业软件、边缘设备和客户现场交付而言，原生二进制有明显吸引力：

• 不再直接交付业务源码；
• 客户端不必管理完整 Composer 工程；
• 程序入口和依赖更集中；
• 可以生成命令行程序或动态库；
• 启动路径更可控。

但“二进制”不等于“完全没有运行时依赖”。官方文档仍涉及 PHPX、PHP Embed、libphp 以及静态或动态链接。最终是否能只复制一个文件运行，要看具体构建方式、目标平台和依赖库，不能把产品页上的“原生可执行文件”想象成必然零依赖的静态 ELF。

调试方式会变得更接近系统编程

AOT 把一部分 PHP 函数变成原生函数后，传统 debug_backtrace() 未必能完整呈现所有原生调用路径。崩溃、ABI 错误、扩展边界和内存问题，也可能需要 GDB、符号表或 Sanitizer 参与排查。

对 PHP 开发者来说，能力边界会从“会写业务和调框架”向下扩展：类型设计、编译链、内存模型和性能分析的重要性会上升。

哪些项目值得尝试，哪些项目现在不必折腾

AOT 最容易制造的误解，是把一个计算基准的提升推广到所有 Web 系统。

假设某个接口耗时 100 毫秒：

PHP 业务计算：1 ms
MySQL：45 ms
Redis：8 ms
外部 RPC：40 ms
序列化与网络：6 ms

即使 AOT 把 PHP 计算从 1 毫秒压缩到 0.1 毫秒，接口也只是从 100 毫秒变成 99.1 毫秒。数据库和网络不会因为 PHP 变成机器码就自动加速。

更值得优先尝试的场景

• 数值计算、规则计算和算法服务；
• 数据解析、压缩、加密与格式转换；
• 独立 CLI 工具；
• 定时任务和批处理程序；
• 常驻消费者与后台进程；
• 商业软件和私有化二进制交付；
• 需要调用 C++ SDK 的项目；
• 希望把部分 PHP 逻辑编译成扩展的场景。

需要压测后再决定的场景

• Hyperf、Swoole HTTP Server；
• API 网关；
• WebSocket 服务；
• 消息队列消费者；
• 高频协议解析服务。

这些项目可能同时拥有 I/O 热点和 CPU 热点。Swoole 协程解决的是并发等待，AOT 解决的是代码执行，两者可以叠加，但最终收益必须由真实 Flame Graph 和压测数据决定。

现阶段不必急着迁移的场景

• 普通 Laravel、ThinkPHP 管理后台；
• 大量使用模板、动态配置和插件的系统；
• WordPress 一类高度动态的生态；
• 计算量很小的 CRUD 接口；
• 严重依赖反射、代理、魔术方法和动态容器的框架代码；
• 需要频繁热更新、直接修改源码的传统交付环境。

是否使用 AOT，首先是工作负载与交付模式的选择，其次才是语言性能的选择。

方向推演：PHP 可能长出另一条技术路线

下面这些不是 Swoole 官方路线图，而是根据当前编译模型做出的工程推演。预览版最终会走到哪里，仍取决于兼容性、授权、工具链和社区采用情况。

第一条路：PHP CLI 工具真正参与原生分发

PHP 很适合写字符串处理、HTTP 调用、文件转换和自动化脚本，却很少成为公开 CLI 工具的首选语言。原因不完全是性能，更是交付：用户必须先安装正确版本的 PHP、扩展和 Composer 依赖。

如果 AOT 能把这些工具编译为平台二进制，PHP 就有机会进入原本由 Go 和 Rust 主导的 CLI 分发场景：

源代码扫描器
配置迁移工具
日志分析器
数据库维护工具
代码生成器
运维客户端

这是我认为最现实的方向。CLI 项目入口清晰、生命周期短、框架魔法较少，比直接编译一个庞大的 Laravel 应用更适合当前 AOT 模型。

第二条路：Swoole 协程负责 I/O，AOT 负责计算

Swoole 过去解决了 PHP “如何高效等待”的问题：协程、事件循环、连接池和常驻服务，让 PHP 不必再把每个请求都绑定到传统同步阻塞模型。

AOT 试图解决另一个问题：PHP 在不等待时，如何更高效地计算。

Swoole 协程：减少 I/O 等待期间的资源浪费
Swoole AOT：减少热点计算中的解释、装箱和动态调用

两者结合后，PHP 才可能同时在 I/O 密集与部分 CPU 密集场景中提高上限。但这不意味着它会自动战胜 Go 或 Rust，因为调度器、内存占用、GC、扩展边界和编译质量依旧决定最终表现。

第三条路：用受限 PHP 编写原生扩展

官方编译器支持 -m ext 扩展模式，可以生成 .so、.dylib 或 .dll。如果这条路线成熟，PHP 开发者未来可能不必手写大量 Zend C API，就能把一段强类型 PHP 编译为原生扩展，再提供给普通 ZendPHP 项目使用。

./swoole_compiler my-extension/ -O2 -o my_extension -m ext

它可能降低三类能力的门槛：

• 把热点算法封装成扩展；
• 将商业核心逻辑以二进制形式交付；
• 在普通 PHP 项目中复用 AOT 生成的原生模块。

这甚至可能比“整个框架全部 AOT”更快进入真实生产：不动现有 Web 架构，只把最值得优化、最需要保护的部分编译掉。

第四条路：PHP 与 C++ 的边界被进一步打通

Swoole AOT 提供了 PHPX 与 C++ 互操作能力。官方文档给出的思路，是让 C++ 函数使用 php:: 类型声明参数和返回值，再从 PHP 直接调用。

简化后的 C++ 函数类似：

#include <phpx.h>

php::String greet(php::String name)
{
    return php::String("Hello, ") + name;
}

php::Int add(php::Int left, php::Int right)
{
    return left + right;
}

PHP 侧仍然保持熟悉的调用方式：

<?php
declare(strict_types=1);

use native_types;

function main(): void
{
    echo greet("World") . "\n";
    echo add(10, 20) . "\n";
}

这类能力适合图像、音视频、科学计算、硬件 SDK 和已有 C++ 资产。但真正进入生产，还要认真处理 ABI、内存所有权、异常边界、线程模型和依赖分发。所谓“无胶水代码”，不应该被理解成“没有工程成本”。具体接口应以官方 C++ 互操作文档为准。

第五条路：PHP 生态可能分成两种语言气质

未来可能长期共存两种 PHP：

一种是我们熟悉的 ZendPHP：动态、灵活、部署简单，适合 Web、模板、插件和快速业务迭代。

另一种是 AOT 约束下的 PHP 子集：严格类型、明确入口、限制动态特性、强调编译期确定性，适合原生程序、计算模块和二进制交付。

它们未必互相取代。就像 Python 同时拥有 CPython、Cython、Numba 和各种原生扩展路线，PHP 也可能保留动态生产力，同时在需要性能与交付能力的地方选择更严格的编译模型。

真正的问题不是“PHP 应不应该抛弃动态性”，而是：

PHP 能否让开发者按场景选择动态性，并清楚知道每一次动态选择付出了什么代价。

必须泼的几盆冷水

技术演进需要想象力，更需要边界感。

它仍是商业闭源软件

当前 AOT 编译器不提供完整公开源码。按照现有官方 FAQ，非商业应用可以免费使用，商业应用需要购买授权；具体范围仍应以使用时的最新条款为准。闭源并不等于技术无价值，但会影响可审计性、供应链信任、长期维护和社区贡献方式。

尤其当我们谈“自举”时，开源社区能够从零复现的自举，与厂商发布一个自举后的二进制，在工程透明度上不是同一回事。

“接近 C++”只在特定代码上成立

原生整数循环、固定对象布局和可内联函数，确实有机会接近 C++ 生成代码。但 PHP 数组、字符串、动态对象、Zend 扩展调用和 I/O 等待仍然存在真实成本。

一段 fib() 快几百倍，不能推出 Laravel 订单接口也会快几百倍。

“绝对内存安全”是过强表述

即使用户层 PHP 没有裸指针，底层仍包含 C++、Zend Engine、扩展、动态库和 ABI 交互。只要系统进入原生世界，就不能仅凭语言表层没有 unsafe 关键字，便宣布整个执行栈绝对安全。

更严谨的说法是：AOT 可以保留 PHP 用户代码较高层的内存管理体验，但底层原生组件仍需传统系统工程的安全审计。

文档和兼容性仍在快速变化

安装页、Release 版本、动态语法说明和部署依赖之间仍有需要持续核对的地方。今天不能编译的语法，未来可能支持；今天允许回退 ZendVM 的路径，未来也可能调整。

因此，现在最合适的态度不是全面迁移，而是选一个边界清晰的 CLI 或计算模块，建立独立验证项目，亲自测试：

• 能否正确编译；
• 与 ZendPHP 的结果是否一致；
• 性能提升来自哪里；
• 二进制依赖能否接受；
• 调试和发布成本是否值得。

自举不是终点，而是 PHP 开始重新定义边界

Swoole AOT 还没有让 PHP 成为下一个 Go 或 Rust。

它不是 PHP 官方编译器的重写，不是 Zend Engine 的彻底替代，也没有让每一个 Laravel、ThinkPHP、Hyperf 项目自动获得十倍性能。它目前还是商业闭源的预览产品，兼容性、构建环境和部署依赖都需要时间验证。

但如果因此认为它只是“又一个 PHP 加密器”，同样低估了这件事。

从 Opcode 加密走向原生机器码，从部署源码走向二进制交付，从依靠 ZendVM 执行一切走向原生代码与 Zend 生态混合执行，Swoole AOT 正在尝试改变的，是 PHP 的工程边界。

一门语言是否成熟，不只看它能写多少网站，还要看它能不能制造自己的工具、管理自己的运行时，并走出最初为它划定的使用场景。

自举不是语言登顶的勋章，而是它终于有能力制造下一把梯子。

Swoole AOT 的这把梯子还很新，甚至有些摇晃。它能不能通向更广阔的原生程序世界，现在没人能下定论。

但它至少证明了一件事：

PHP 的终点，从来不必只是等待下一次 HTTP 请求。

参考资料

版本、授权和兼容性信息核查于 2026 年 7 月 15 日；AOT 仍在快速迭代，实际使用前应再次核对官方文档。

• Swoole AOT：安装软件
• Swoole AOT：编译
• Swoole AOT：执行过程
• Swoole AOT：兼容性
• Swoole AOT：性能
• Swoole AOT：C++ 互操作
• Swoole TypePHP Releases
• Go 1.5 Release Notes：The Implementation
• Rust Compiler Development Guide：What Bootstrapping Does
• PHP 官方 OPcache 文档源码