直接改php.ini的memory_limit常无效，因Composer用CLI模式PHP，而用户常误改Apache或php-fpm配置；须用php --ini确认“Loaded Configuration File”路径，若为空则CLI使用编译默认值（通常128M）。
直接改 php.ini 的 memory_limit 通常无效，因为 Composer 默认用 CLI 模式的 PHP，而你改的很可能是 Apache 或 php-fpm 的配置文件——两者路径不同、配置不互通。
确认当前 CLI 使用的 php.ini 路径
运行 php --ini 查看 “Loaded Configuration File” 行；若显示为空或 “(none)”，说明 CLI 没加载任何 php.ini，此时 memory_limit 实际是编译默认值（常为 128M）。常见 CLI 配置路径：
- Ubuntu/Debian：
/etc/php/8.2/cli/php.ini - macOS Homebrew：
/usr/local/etc/php/8.2/php.ini - Docker 官方镜像：
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini类路径下
改完必须重启终端或重新加载 shell 配置（如 source ~/.zshrc），否则新设置不会被当前会话识别。
为什么设成 -1 还报错 Allowed memory size exhausted
现象：执行 php -d memory_limit=-1 composer install 仍失败。核心原因不是 PHP 层没放开，而是：
立即学习“PHP免费学习笔记（深入）”；
-
which composer返回/usr/bin/composer？那是 shell wrapper，-d参数被忽略，得用php -d memory_limit=-1 /path/to/composer.phar install - 系统级限制生效：
ulimit -v（虚拟内存）或ulimit -m（物理内存）过低，尤其在 CI 容器中常见 - Xdebug 已启用：它会让内存占用翻倍甚至更高，临时禁用更有效：
php -d extension= -d memory_limit=-1 composer install - Composer 自身求解器主动中止：当依赖组合数超 5000，新版 Composer 会直接退出，加内存无用，必须换策略
composer install 和 update 的内存行为根本不同
composer install 理论上只读 composer.lock，不该爆内存；但现实里它常比 update 更慢、更容易失败，原因在于：
-
composer.lock文件过大（>5MB）：含大量 dev 包哈希、完整 autoload 映射，解析时全载入内存 - 实际执行了隐式
update：命令中混入--with-all-dependencies或别名触发了求解器 - 插件干扰：旧版
hirak/prestissimo或自定义插件反复扫描vendor/目录
安全做法是显式跳过所有求解逻辑：composer install --no-interaction --no-progress --no-dev --prefer-dist。CI 中务必固定这组参数，避免环境变量悄悄激活更新模式。
真正有效的长期配置不是调高 memory_limit
把 memory_limit = 2G 写进 CLI 的 php.ini 是可行的，但掩盖了问题本质。更可持续的做法是：
- 删掉
composer.json里不用的require-dev条目（哪怕不装，它们也参与依赖图构建） - 收紧版本约束：把
"^1.0"改成"^1.25"或锁定小版本，大幅缩小 SAT 求解空间 - 升级到 Composer 2.9.6+：其并行下载和改进的求解算法对大项目有实测 30%+ 内存下降
- CI 中禁用 Xdebug 并用
php -d memory_limit=2G显式控制，比依赖COMPOSER_MEMORY_LIMIT更可靠
最易被忽略的一点：COMPOSER_MEMORY_LIMIT 不绕过 PHP 底层限制，它只是 Composer 自己的软性上限。PHP 进程在分配第 2049MB 内存时已被内核 kill，Composer 根本没机会检查这个变量。
