php -d memory_limit=-1 有时不生效，因 Composer v2+ 启动时主动拒绝 memory_limit=-1；应改用 COMPOSER_MEMORY_LIMIT 环境变量配合足够大的 php -d memory_limit（如2G）组合使用。
php -d memory_limit=-1 为什么有时不生效
因为 Composer v2+ 启动后会主动检查 PHP 的 memory_limit，如果发现是 -1（无限制），会直接拒绝运行并报错：Composer requires the memory limit to be set to a value greater than 0。这不是 bug，而是它的安全策略。
真正能绕过这个检查的，是 COMPOSER_MEMORY_LIMIT 环境变量——它由 Composer 自己读取，不触发底层校验。但注意：COMPOSER_MEMORY_LIMIT 只控制 Composer 内部缓存逻辑，**不替代 PHP 的内存限制**；你仍需确保 php -d memory_limit 足够大，否则进程照样 OOM。
- 推荐组合用法：
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=2G composer install - Linux/macOS 下可简写为：
COMPOSER_MEMORY_LIMIT=2G php -d memory_limit=2G composer install - Windows CMD 中记得等号不加空格：
set COMPOSER_MEMORY_LIMIT=2G && php -d memory_limit=2G composer install
COMPOSER_MEMORY_LIMIT 和 php.ini 的 memory_limit 到底谁优先
COMPOSER_MEMORY_LIMIT 是 Composer 自定义的环境变量，只影响它自己的依赖解析、缓存加载等内部行为；而 php -d memory_limit 或 php.ini 中的 memory_limit 是 PHP 解释器层面的硬限制，所有 PHP 代码（包括 Composer 的 Phar 主体）都受其约束。
两者不是“二选一”，而是“上下级”关系：即使 COMPOSER_MEMORY_LIMIT 设为 2G，若 PHP 层只给 128M，Composer 还是会在分配第 129MB 时被杀掉。
- 验证 CLI 当前
memory_limit：运行php -r "echo ini_get('memory_limit');" - 查 CLI 实际加载的
php.ini：运行php --ini，看Loaded Configuration File路径 - CI/CD 中别依赖环境变量继承——GitHub Actions 默认不透传
COMPOSER_MEMORY_LIMIT，显式写两行更稳
composer update 卡在 Resolving dependencies 就一定是内存不够吗
不一定。这个阶段卡住，更常见的原因是依赖冲突引发的指数级版本回溯（SAT 求解失败），而不是单纯内存耗尽。现象是 CPU 占用高、无输出、数分钟不动，最后静默退出或被 OOM killer 杀掉。
此时调高内存可能没用，甚至掩盖真实问题。你应该先确认是否真需要全量更新：
- 生产环境永远用
composer install，不是update - 想升级单个包？用
composer update vendor/package-name，避免重算整棵树 - 怀疑循环依赖？加
-v参数跑一次：composer update -v，观察最后停在哪一行 - 旧版 Composer（composer self-update
CI/CD 中 composer install 失败但本地正常，怎么快速定位
CI 环境（如 GitHub Actions ubuntu-latest）默认容器总内存仅约 7GB，PHP 进程能分到的远少于本地；而且常默认启用 xdebug，会让 Composer 内存占用翻倍以上。
别急着改配置，先做三件事：
- 确认是否启用了 xdebug：
php -m | grep xdebug，CI 中应加参数关掉：php -d zend_extension= -d xdebug.mode=off composer install - 清缓存再试：
composer clear-cache，CI 中缓存损坏概率比本地高得多 - 缩小安装范围：
composer install --no-dev --optimize-autoloader，跳过 dev 依赖 + 生成高效 autoload，能省下 30%+ 内存
最易被忽略的一点：Docker 容器或 CI runner 的 cgroup 内存限制（如 memory: 2g）可能比 PHP 的 memory_limit 更早触发 OOM——这时调 PHP 配置毫无意义，得去调容器或 job 级别的资源上限。
