必须修改 CLI 模式的 php.ini 文件，而非 Apache 或 FPM 的配置；运行 php --ini 查看 Loaded Configuration File 路径，添加 memory_limit = -1 并验证生效。
Composer 安装报错 Allowed memory size exhausted，不是临时加 -d memory_limit=-1 就能一劳永逸的——默认配置会覆盖命令行参数，必须改对位置才生效。
composer install 报 Allowed memory size of XXX bytes exhausted 怎么临时绕过
这是最常遇到的表象：执行 composer install 或 composer update 时 PHP 内存耗尽。临时解决确实可以用命令行强制调高：
- Linux/macOS：
php -d memory_limit=-1 /usr/bin/composer install - Windows：
php -d memory_limit=-1 composer.phar install
但注意：-d memory_limit 只影响当前 php 进程，且如果系统里存在 php.ini 中的 memory_limit 被设为硬上限（如 128M），某些 SAPI（比如 Apache mod_php）可能仍会拦截。更重要的是：这个写法在 CI/CD 或他人复现时极难维护，属于“救火式操作”。
永久生效必须改哪个 php.ini 文件
Composer 启动时用的是 CLI 模式的 PHP，所以必须修改 CLI 对应的 php.ini，不是 Apache 或 FPM 的那个。找法很简单：
- 运行
php --ini，看输出里的Loaded Configuration File路径 - 常见位置：
/etc/php/*/cli/php.ini（Ubuntu/Debian）、/usr/local/etc/php/*/php.ini（macOS Homebrew）、C:\xampp\php\php.ini（Windows XAMPP） - 确认无误后，在该文件末尾加一行：
memory_limit = -1（或至少2G）
改完别忘了验证：php -r "echo ini_get('memory_limit');" 输出应为 -1 或你设的值。如果还是 128M，说明改错了 ini 文件，或者有多个 PHP 版本混用。
为什么 COMPOSER_MEMORY_LIMIT 环境变量有时不生效
Composer 自己支持 COMPOSER_MEMORY_LIMIT 环境变量（如 export COMPOSER_MEMORY_LIMIT=-1），但它只在 Composer 自身内存管理逻辑中起作用，**不改变 PHP 底层的 memory_limit 阈值**。也就是说：
- 当 PHP 已经因超限抛出
Fatal error时，这个变量根本没机会被读取 - 它只对 Composer 内部某些可中断的循环（比如依赖解析）做软限制，不能防止底层
malloc失败 - 优先级低于
php.ini和-d参数，但高于composer.json里的配置
所以它适合做“二次防护”，但不能替代 php.ini 修改。
CI/CD 流水线里怎么安全设内存限制
在 GitHub Actions、GitLab CI 等环境里，不能直接改系统 php.ini，推荐组合方案：
- 用
php -d memory_limit=2G $(which composer) install，显式指定且避免路径歧义 - 提前检查：
php -r "if (ini_get('memory_limit') == -1 || (int)ini_get('memory_limit') ，失败则 abort - 避免用
sudo改全局 ini —— 容器每次重建，改了也白改；更别用sed -i硬替换，容易破坏原有配置结构
真正麻烦的从来不是调大内存，而是有些老旧项目用了大量 fxp/composer-asset-plugin 或自定义 installer，它们在解析过程中会反复 clone 整个包元数据，导致内存占用呈指数增长——这种时候，光调内存只是延缓崩溃，得配合 --no-scripts --no-plugins 先跑通再排查。
