直接加内存限制就能解决，但必须加对地方、加对值：php -d memory_limit=2G composer install（Linux/macOS/Windows CMD）或php -d "memory_limit=-1" composer update（PowerShell），且php必须置于命令最前；COMPOSER_MEMORY_LIMIT=2G为轻量替代方案；改php.ini常无效，因CLI与Web服务使用不同配置文件。
直接加内存限制就能解决，但必须加对地方、加对值，否则还是报 Allowed memory size exhausted。
php -d memory_limit 必须放在 composer 命令最前面
Composer 启动时吃内存的阶段（依赖解析、autoload 扫描）由 PHP CLI 进程承载，php -d 参数能精准覆盖这一进程，且不污染其他环境。
- Linux/macOS/Windows CMD 都支持：
php -d memory_limit=2G composer install（等号两边不能有空格） - PowerShell 中需加引号：
php -d "memory_limit=-1" composer update - 若用
composer.phar，命令必须是php -d memory_limit=2G ./composer.phar install，不能只写./composer.phar——否则-d不生效 -
-1表示无限制，本地开发可用；CI/CD 或 Docker 容器里建议写死为2G或3G，避免被 OOM killer 杀掉进程
COMPOSER_MEMORY_LIMIT 环境变量更轻量但作用范围不同
这是 Composer 原生识别的变量，优先级高于 php.ini，只作用于 Composer 自身逻辑（比如 SAT 求解器），不影响其他 PHP 扩展行为。
- 临时生效（当前终端）：
export COMPOSER_MEMORY_LIMIT=2G（Linux/macOS）或set COMPOSER_MEMORY_LIMIT=2G（Windows CMD） - CI 脚本中推荐直接注入：
COMPOSER_MEMORY_LIMIT=2G composer install --no-interaction - 验证是否生效：
php -r "echo getenv('COMPOSER_MEMORY_LIMIT');"，应输出2G - 别在
.env或phpunit.xml里设PHP_MEMORY_LIMIT——Composer 不读这些
为什么改 php.ini 往往白忙活
PHP CLI 和 Web 服务器（如 PHP-FPM）通常加载不同的 php.ini 文件。你改了 Apache 的配置，对终端跑的 Composer 完全没影响。
- 先查 CLI 用的是哪个配置：
php --ini，看 “Loaded Configuration File” 路径（常见于/etc/php/8.2/cli/php.ini） - 改完后验证：
php -r "echo ini_get('memory_limit');"，输出应为2147483648或2G - Docker、GitHub Actions、GitLab CI 等环境基本不允许改
php.ini，硬改会失败或被覆盖 - 全局调高
memory_limit有风险：一个失控的 Web 脚本可能吃光整台服务器内存
Resolving dependencies 卡住 ≠ 网络慢，很可能是内存不够
这个阶段完全不走网络，但会高频扫描 vendor/ 和项目目录下的 PHP 文件。一旦内存不足，Composer 就会反复重试、静默崩溃，甚至被系统 Killed（日志只剩 Killed）。
- 检查是否启用了 xdebug：
php -v输出含xdeb就说明开着，它会让内存占用翻倍以上 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 确认
composer.json的autoload和autoload-dev没把node_modules/或dist/目录包含进去 -
composer update比composer install更耗资源，生产环境禁止在线执行，所有更新应在本地完成并提交composer.lock
真正容易被忽略的是：内存不足常表现为“卡住”而非明确报错，尤其在 CI 环境里，Killed 日志不会告诉你原因；另外，COMPOSER_MEMORY_LIMIT 和 php -d memory_limit 是两套机制，前者管 Composer 内部逻辑，后者管整个 PHP 进程，混用或只设其一都可能漏掉关键瓶颈。
