应优先用php -d memory_limit=-1 composer install临时解决，因该命令在进程启动前强制解除php内存限制，绕过环境变量和配置干扰，且不修改全局php.ini；windows powershell需加引号，composer.phar调用时参数顺序不可错。
Composer 报 Allowed memory size exhausted，不是项目太大，而是 PHP 进程在解析依赖、解压包或生成 autoloader 时被 memory_limit 卡死了。默认 128M 或 256M 完全不够用，但直接改 php.ini 是错的——它会影响所有 CLI 脚本，且 CI 环境根本没法动配置。
php -d memory_limit=-1 是最可靠的一次性方案
这条命令强制 PHP 当前进程不限内存，Composer 启动前就生效，绕过所有环境变量和配置干扰：
-
php -d memory_limit=-1 composer install（Linux/macOS/Windows CMD） - Windows PowerShell 要加引号：
php "-d" "memory_limit=-1" composer install - 如果用了
composer.phar，必须写成php -d memory_limit=-1 composer.phar install，顺序不能错 - 别用
php -d memory_limit=-1 $(which composer)—— 这会调用 shell wrapper，-d参数可能被丢弃
COMPOSER_MEMORY_LIMIT 环境变量只对 Composer 自身逻辑起作用
这个变量控制的是 Composer 内部缓存大小，不绕过 PHP 底层限制。设了 COMPOSER_MEMORY_LIMIT=-1 却没调高 php -d memory_limit，等于白设：
- 正确写法：
COMPOSER_MEMORY_LIMIT=-1 composer install（Linux/macOS） - Windows CMD：
set COMPOSER_MEMORY_LIMIT=-1 && composer install - PowerShell：
$env:COMPOSER_MEMORY_LIMIT="-1"; composer install - 值必须是
-1或整数字节（如2147483648），不能写2G或带引号的"-1" - 它对
composer update效果明显，但install阶段大量解包操作由 PHP 直接承担，不受此变量控制
为什么有时调高内存也没用？真凶往往不是内存
看到 OOM 就加内存，容易忽略真正拖垮 Composer 的行为：
- 启用了
xdebug：本地开发常开着，但它会让内存占用翻倍以上；CI 中务必关掉：php -d zend_extension= -d xdebug.mode=off composer install - 循环依赖或宽泛 autoload 规则：比如
"psr-4": {"": "src/"}扫描了整个vendor目录 - 旧版 Composer（1.x）或低版本 PHP（如 7.4 + Composer 2.5+）存在兼容问题，导致依赖解析反复重试
-
composer.lock损坏或 vendor 残留，先清掉再试：rm -rf vendor composer.lock && composer clear-cache - Docker 容器里没同步 cgroup 限制：即使设了
COMPOSER_MEMORY_LIMIT=-1，宿主机 cgroup 仍可能 kill 掉进程
CI/CD 和 Docker 环境最容易漏掉的关键点
本地能过、CI 报错，90% 是环境没对齐：
- GitHub Actions 中，
run: composer install不继承你本地的环境变量，必须显式声明：env: COMPOSER_MEMORY_LIMIT: "-1"
- Dockerfile 里光写
ENV COMPOSER_MEMORY_LIMIT=-1不够，得确保它在RUN composer install命令之前生效 - CI 默认 PHP 版本可能不是你预期的那个，先加一步确认：
php -v && php --ini && php -r "echo ini_get('memory_limit');" - 某些 CI 平台（如 GitLab Runner）使用非交互式 shell，
export不生效，优先用php -d memory_limit=2G这种硬覆盖方式
真正麻烦的从来不是“怎么设”，而是不同环境之间配置没对齐：PHP CLI 版本、memory_limit 实际值、xdebug 开关状态、Composer 版本、甚至 shell 解析行为——这些细节稍有偏差，就会让同一行命令在本地跑通、在 CI 里静默失败。
