首选解法是php -d memory_limit=2G composer install，因其直接绕过php.ini和环境变量限制，仅对当前CLI进程生效，兼容CI/CD与本地环境，且避免COMPOSER_MEMORY_LIMIT无法覆盖PHP底层限制的问题。
直接加内存限制是最有效解法，但必须针对 CLI 模式、用 php -d memory_limit 前缀，而不是改 php.ini 或依赖环境变量。
为什么 php -d memory_limit=2G composer install 是首选
Composer 内存耗尽本质是 PHP CLI 进程被默认 memory_limit=128M 卡死，不是 Composer 自身设计缺陷。用 -d 参数能绕过所有配置文件干扰，只对当前命令生效：
-
php -d memory_limit=2G composer install—— 兼容性好，CI/CD 和本地都稳 -
php -d memory_limit=-1 composer update—— 本地开发可用，但 CI 中慎用（容器可能被 OOM kill） - 若用
composer.phar，必须写成php -d memory_limit=2G ./composer.phar install，否则-d不生效 - PowerShell 用户注意引号：
php -d "memory_limit=-1"，否则参数解析失败
COMPOSER_MEMORY_LIMIT 环境变量到底靠不靠谱
它确实被 Composer 原生支持，但作用范围有限：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只控制 Composer 自身逻辑（如依赖求解器），不覆盖 PHP 底层
memory_limit - 优先级低于
php -d，高于php.ini；设成-1时，若php.ini是128M，依然会爆 - Linux/macOS：可
export COMPOSER_MEMORY_LIMIT=2G；Windows CMD 必须set COMPOSER_MEMORY_LIMIT=2G && composer install - Docker 或 GitLab CI 中，仅设此变量不够，还得同步调大容器内存（如
--memory=4g）
composer update 比 composer install 更容易崩的真相
因为 update 要全程在内存中重建依赖图：下载全部元数据、跑 SAT 求解器、校验 hash、生成新 composer.lock，峰值常超 1.5GB；而 install 只按 lock 文件还原，通常不到 200MB：
- 生产环境禁止直接跑
composer update，所有更新必须在开发机完成并提交composer.lock - 真要在线更新，先
composer update --dry-run看影响范围，再用composer update vendor/package-name精准更新 - 加
--no-plugins --no-scripts能跳过插件预加载和脚本执行，显著压低内存峰值 - 若项目含大量废弃包（如旧版
symfony/class-loader），它们的不规范composer.json会触发额外递归解析——先人工清理require-dev
dump-autoload 报内存不足？大概率是扫描了不该扫的目录
这不是 autoload 机制问题，而是 Composer 在生成映射时被迫处理了非代码文件：
- 检查项目根目录是否误放了
logs/、storage/、node_modules/或巨型 JSON 配置 - 确认
composer.json的autoload和autoload-dev没包含dist/或build/ - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 启用优化可降内存压力：
composer dump-autoload -o（生成类映射）、--apcu-autoloader（需 APCu 扩展）
真正容易被忽略的是：即使加了 2G，如果 Docker 容器本身只分配了 2GB 内存，或系统 /tmp 分区只剩几百 MB，PHP 进程仍会被 OOM killer 杀掉——得同步查容器配额和临时目录空间。
