直接加php -d memory_limit=-1参数最快生效，本质是解除PHP CLI进程的memory_limit限制；本地开发可用-1，CI/CD或Docker中推荐设2G~3G上限，避免OOM；Windows需注意引号和等号格式。
直接加内存参数就能过，别改 php.ini，也别指望 clear-cache 单独解决。
php -d memory_limit=-1 是最快生效的解法
Composer 内存耗尽本质是 PHP CLI 进程被 memory_limit 拦住，不是 Composer 本身写得差。默认 128M 或 256M 在 Laravel/Symfony 项目里连依赖树都扫不完。
- 本地开发可放心用
php -d memory_limit=-1 composer install，-1 表示不限制（实际受限于系统可用内存） - CI/CD 或 Docker 环境慎用 -1：GitHub Actions、GitLab CI 默认容器内存有限，推荐显式设为
php -d memory_limit=2G或3G - Windows CMD 用户注意等号不能有空格：
php -d"memory_limit=-1" composer install；PowerShell 中需加引号：php -d "memory_limit=-1" composer install - 如果调用的是
composer.phar，必须把php -d放最前：php -d memory_limit=2G ./composer.phar update
COMPOSER_MEMORY_LIMIT 环境变量更轻量但有边界
这个变量是 Composer 原生支持的机制，只影响它自己的依赖解析逻辑，不改动 PHP 底层限制，比全局 memory_limit 更精准。
- 临时生效（当前终端）：
export COMPOSER_MEMORY_LIMIT=2G（Linux/macOS）或set COMPOSER_MEMORY_LIMIT=2G（Windows CMD） - 它的优先级高于
php.ini，但低于php -d参数——后者会直接覆盖它 - CI 脚本中推荐写成
COMPOSER_MEMORY_LIMIT=2G composer install，干净且易维护 - 注意：它对
composer dump-autoload也生效，但该命令本身内存占用低，一般不需要专门设
磁盘空间和临时目录才是隐藏杀手
报 Allowed memory size exhausted 有时是假象——真实原因是 /tmp 或 %TEMP% 分区满了，导致解压失败后 PHP 进程异常退出，错误被误判为内存问题。
- 先查真实瓶颈：
df -h /tmp（Linux/macOS）或dir %TEMP%（Windows） - 临时改道：
export TMPDIR="$HOME/tmp" && mkdir -p "$TMPDIR" && chmod 700 "$TMPDIR" - 同时迁移缓存目录避免叠加压力：
export COMPOSER_CACHE_DIR="$HOME/.composer-cache" - 验证是否生效：
composer config cache-dir和echo $TMPDIR应返回新路径 - 只改
COMPOSER_CACHE_DIR不改TMPDIR，解压阶段仍会卡在/tmp空间不足
vendor/autoload.php 生成失败不是 autoload 的锅
这个报错常出现在 composer install 最后一步，看起来像 autoloader 出问题，其实是 Composer 扫描了不该扫的文件——比如日志、巨型 JSON 配置、或 node_modules/ 被误包含进 autoload 配置。
- 检查
composer.json的autoload和autoload-dev字段，确认没把logs/、storage/、dist/、node_modules/加进去 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 如果项目根目录下有大体积非代码文件（如
logs/app.log达几百 MB），先移走再试 - 某些老旧包（如
symfony/class-loader）的元数据不规范，会触发重复解析——删掉require-dev中不用的包能显著降低内存峰值
真正容易被忽略的是：错误里写的路径，未必是你正在操作的目录；Permission denied 或 No space left on device 往往指向 /tmp 或 ~/.composer/cache，而不是 vendor/。不看错误信息里的具体路径就动手，大概率白忙活。
