PHP转EXE内存溢出主因是打包工具（如Box）自身内存不足，需调大执行box build的PHP进程内存限制（如php -d memory_limit=2G），而非运行时memory_limit；同时精简依赖、排除冗余文件、优化自动加载，并注意EXE封装层的PE加载限制与运行时配置覆盖。
PHP 转 EXE 时内存溢出，本质不是 PHP 内存限制问题
报错 Allowed memory size exhausted 或直接进程被系统终止，往往不是因为 memory_limit 设得太低——而是你用的打包工具（如 Box、PHP Desktop、第三方 GUI 封装器）在构建阶段加载了大量 PHP 文件、扩展或递归扫描依赖，导致打包进程自身内存爆掉。PHP 运行时的 memory_limit 对打包过程完全无效。
调整打包进程内存：以 Box 为例
Box 是最常用的 PHP PHAR 打包工具，它基于 Composer 和 Symfony Console，本身是 PHP 脚本，因此启动时受当前 PHP 配置影响。关键点在于：你要调大「运行 box build 这个命令的 PHP 进程」的内存限制，而不是最终 EXE 里 PHP 的限制。
- 临时生效：运行前加
-d memory_limit=-1（不限制）或-d memory_limit=2G - 示例命令：
php -d memory_limit=2G vendor/bin/box build
- 若用 Windows 批处理，确保调用的是 CLI 版 PHP（
php.exe），不是 Apache 模块版；检查php --ini确认加载的是php.ini-development或自定义配置 - 某些旧版 Box（v3.x）会因
opcache.enable_cli=1导致内存占用翻倍，可临时关掉：-d opcache.enable_cli=0
EXE 封装层（如 WinBinder、PHP Desktop）的内存陷阱
真正生成 Windows 原生 EXE 的工具（非纯 PHAR），比如 WinBinder 或基于 Electron + PHP-CGI 的方案，会在启动时预加载整个 PHP 解释器+全部扩展+你的代码。这时溢出常发生在：静态链接的扩展太多、vendor 目录包含大量未剪裁的开发依赖（如 phpunit、symfony/debug）、或 入口文件 require 了全量框架自动加载器。
- 务必在打包前执行：
composer install --no-dev --optimize-autoloader
- 检查
box.json中的directories和files是否包含tests/、docs/、.git/等冗余路径 - 避免在
index.php里require 'vendor/autoload.php'后再require整个src/；改用 PSR-4 自动加载并精简命名空间映射 - 某些 GUI 封装器（如 ExeOutput for PHP）会把 PHP DLL 和资源全塞进单个 EXE，此时超过 500MB 就容易触发 Windows 内存映射失败——这不是 PHP 错，是 PE 加载器限制
最终 EXE 运行时的 memory_limit 仍需单独设
打包成功后，EXE 启动的 PHP 子进程默认沿用其内置 php.ini 的 memory_limit（常见为 128M）。如果你的程序运行中真需要更多内存，不能靠打包时调大，而要在 EXE 启动逻辑里覆盖：
- 在主 PHP 入口顶部加：
ini_set('memory_limit', '512M'); - 或更稳妥：用
php -c指向一个定制php.ini（需随 EXE 一起分发，并确保路径可读） - 注意：Windows 下部分封装器不支持
ini_set()修改memory_limit（尤其当使用线程安全 TS 版 PHP 且memory_limit在启动时硬编码），此时唯一办法是替换 EXE 内嵌的php.ini
真正卡住的地方，往往是打包工具链自己吃掉了 3GB 内存却没报错，只静默崩溃——盯住任务管理器里的 php.exe 进程内存曲线，比看错误日志更有用。
