ExeOutput for PHP 是兼容 PHP 5.2–7.4 最佳的开箱即用打包工具，内置可选旧版 PHP 解释器，支持 mysql_connect() 等废弃函数及 magic_quotes_gpc 等老特性，实测适配遗留 CMS；Bambalam 和 ZZEE PHPExe 次之，PHC 等已不推荐。
ExeOutput for PHP 是目前对老版 PHP（如 5.3–7.4）兼容性最好、开箱即用的打包工具，尤其适合未升级 PHP 的遗留项目。它不依赖系统环境，内置 PHP 解释器，能直接打包 mysql_connect()、ereg() 等已废弃但仍在老项目中使用的函数——只要你的代码能在本地 Windows 上跑通 php.exe，它大概率就能打成 EXE。
哪些工具真能跑通 PHP 5.6 或更老的代码？
不是所有“PHP 转 EXE”工具都支持旧语法和扩展。很多新工具默认基于 PHP 8+ 构建，一遇到 mysql_* 函数或 create_function() 就报错或静默失败。
-
ExeOutput for PHP：官方明确支持 PHP 5.2–7.4，安装时可手动指定嵌入的 PHP 版本（如选php-5.6.40-Win32-VC11-x86），实测可运行含magic_quotes_gpc逻辑的 CMS 系统 -
Bambalam PHP EXE Compiler：轻量开源，依赖你本地已有的 PHP for Windows 二进制包，只要你的php.exe能跑老项目，它就能打包；但不支持pdo_sqlsrv等 VC14+ 编译的扩展 -
ZZEE PHPExe：商业工具，提供历史版本下载（含 PHP 5.3.x 内置包），界面简陋但稳定，适合打包纯 CLI 工具类脚本（如日志分析、数据库迁移） -
PHC和PHP Compiler：已多年未更新，对 PHP 5.5+ 支持极差，__autoload()、array_map()带匿名函数等都会编译失败，不建议尝试
打包前必须验证的三件事
老项目打包失败，80% 源于没提前检查运行时依赖。别等编译完再双击报错。
- 确认
php -v输出的版本与你打算嵌入的版本一致（例如项目写死用mysqli_connect()却塞进 PHP 5.2 包，会直接启动失败） - 检查
php.ini中启用的扩展是否全被工具支持：extension=php_mysqli.dll可以，但extension=php_sqlsrv_72_ts.dll（SQL Server 官方驱动）多数打包工具根本不识别 - 禁用所有运行时动态加载扩展的代码，例如：
dl('php_curl.dll')或extension_loaded('xdebug')判断——打包后这些路径不存在，会中断执行
为什么不用自制方案（如 Caddy + PHP）？
理论上你可以用 Caddy + 精简版 php-cgi.exe 手动搭一个绿色包，但对老项目反而更危险：
立即学习“PHP免费学习笔记（深入）”；
- PHP 5.3–5.6 的
php-cgi.exe默认不带openssl、mbstring，而老 CMS（如早期 WordPress 插件、DedeCMS）大量依赖它们 - 你需要手动补全
libeay32.dll、ssleay32.dll等 VC9 运行时 DLL，且版本必须严格匹配（VC9 ≠ VC11） - 打包成单 EXE 需配合
Inno Setup或NSIS，一旦解压路径含中文或空格，include('./config.php')就可能失效——老项目极少做路径容错
注意：ExeOutput for PHP 默认把项目解压到 %TEMP% 下随机目录，所以所有相对路径（如 require 'inc/db.php'）必须基于入口文件位置，不能依赖 __DIR__ 绝对定位——这是老项目打包后白屏最常见的原因。
真正麻烦的从来不是“怎么打成 EXE”，而是“打完能不能在客户那台 Win7 + IE8 的老电脑上点开就用”。选工具前，先拿目标环境跑一遍 php -f index.php，再决定嵌入哪个 PHP 版本。
