PHP 8.6 Beta 2 发布后扩展兼容性检查应从哪里开始

PHP 8.6.0 Beta 2 更适合被当作“扩展兼容性演练包”，而不是可直接升级的运行时。官方预发布页把它列为测试构建，并明确提醒不要用于生产；因此检查重点不是“能不能启动 PHP”，而是自研扩展、PECL 扩展、内部 API 和外部库能否在同一套隔离环境中重新构建并完成回归。

不用等正式版发布再启动适配，PHP 8.6 Beta 2 版本已经锁定核心API的大部分改动，现在排查可以提前避开正式版发布后的集中升级卡点。

PHP 8.6 Beta 2 到底意味着什么：先把测试边界画出来

官方预发布页面显示，PHP 8.6.0beta2 的源码包在 2026 年 8 月 27 日提供，Windows 构建还包含供扩展开发使用的 Development package。页面同时说明这些下载只用于测试，发现问题应通过 GitHub Issues 反馈。这个信号很明确：Beta 2 的价值在于提前暴露回归，不在于替生产环境提供稳定承诺。

所以第一步是复制一份与线上不同的容器或虚拟机，单独保存 PHP 二进制、开发头文件、编译器、系统库和扩展源码。不要把测试扩展直接覆盖线上 extension_dir，也不要因为一次 CLI 命令成功就判断 FPM、队列消费者和 Web 请求都兼容。

扩展兼容性不要只看能否加载：四层检查更稳

扩展失败通常会被误归因于“PHP 8.6 不兼容”，但实际可能是构建工具、内部接口、PHPT 用例或外部库中的任一层。尤其是 PHP 8.6 的升级说明已经包含新的 Streams errors API 等变化；第三方扩展若调用内部函数或依赖头文件细节，风险会高于只使用稳定用户态 API 的扩展。

用 Beta 2 的 phpize 和 php-config 重建一遍

PHP 官方手册给出的共享扩展路径仍然是 phpize、./configure、make、make install。关键是这些命令必须来自 Beta 2 环境，而不是开发机上默认指向 PHP 8.4 或 8.5 的工具：

# 让构建脚本使用隔离环境里的 PHP 8.6 工具链
PHP86=/opt/php-8.6-beta2
cd ext-demo
$PHP86/bin/phpize
./configure --with-php-config="$PHP86/bin/php-config"
make -j2

# 先确认模块和目标 PHP 的扩展目录一致，再加载测试
$PHP86/bin/php-config --extension-dir
make test TESTS="tests/*.phpt"
$PHP86/bin/php -d extension="$PWD/modules/ext_demo.so" -m

不要省略 php-config 的路径核对。扩展文件即使成功生成，若被装进另一套 PHP 的目录，最后看到的仍可能是“加载失败”或“找不到模块”，这不是源码兼容性结论。

从冒烟到业务回归：失败要能定位

加载成功后先做最小冒烟：确认扩展是否出现在 php -m，核心函数的返回类型是否符合预期，资源创建、释放和异常路径是否正常。接着跑 PHPT，再把应用中真正依赖该扩展的查询、序列化、网络请求或队列任务放进隔离回归集。只测“首页能打开”很容易漏掉长连接、错误处理和边界输入。

记录结果时至少保留 PHP 构建标识、扩展源码提交、编译器、系统库版本、configure 参数、失败日志和最小复现。PHP 8.6 的 UPGRADING 文件与官方预发布页都应作为更新入口；当 Beta 3 或正式版变化后，重新核对这两处，不要沿用 Beta 2 的结论。

什么时候可以进入灰度评估

只有在四层检查都通过、关键业务回归有可重复记录、外部库版本也被固定后，才适合在不承载真实用户请求的灰度环境继续观察。Beta 2 仍然不能直接作为生产版本；如果遇到内部 API 变更或扩展构建错误，优先提交包含最小复现的 issue，并把应用留在稳定 PHP 版本上。

常见问题

扩展能加载，是否就代表 PHP 8.6 兼容？

不是。加载只证明模块被当前 PHP 接受，还要覆盖核心调用、PHPT、异常路径和真实业务组合。

应该先升级 PHP，还是先重建扩展？

先在隔离环境重建扩展并跑回归，再评估应用运行时；不要让生产 PHP 和测试扩展交叉覆盖。

从哪里查看 PHP 8.6 的变化？

优先看官方预发布构建页与 php-src 的 UPGRADING 文件。前者确认测试包和发布边界，后者用于定位升级说明和扩展相关变化。