Composer内存不足主因是PHP默认memory_limit过低（如128M），而解析依赖、校验hash、生成autoload等操作需批量建模，峰值易超限；应优先用php -d memory_limit=2G临时提限，CI环境禁用-1以防OOM。
为什么composer install会突然报内存不足
不是依赖本身变大了，而是 Composer 在读取 composer.lock 后，要逐个校验包的 hash、解压、写入 vendor、生成 autoload 映射——这些操作在内存中批量建模。尤其当 lock 文件里有 150+ 包、或含大量 require-dev（如 PHPUnit、PHPStan、Doctrine Fixtures），内存峰值很容易突破默认的 128M。错误信息里出现 Allowed memory size of XXX bytes exhausted 就是明确信号。
php -d memory_limit 和 COMPOSER_MEMORY_LIMIT 怎么选
优先用 php -d memory_limit=2G：它直接改 PHP 解释器的硬限制，覆盖所有环节（包括 autoload 扫描、插件初始化、依赖校验）。COMPOSER_MEMORY_LIMIT=2G 只影响 Composer 自身逻辑，如果 PHP 底层仍卡在 128M，这个变量就无效。
- Linux/macOS 直接运行：
php -d memory_limit=2G composer install - Windows CMD 要加引号：
php -d "memory_limit=2G" composer install - PowerShell 中
-1必须引号：php -d "memory_limit=-1" composer update - CI 环境（如 GitHub Actions）禁用
-1，固定写2G或3G，避免 OOM killer 杀进程
vendor/autoload.php 生成失败也归为内存不足？
这其实是假象。真正原因是 composer dump-autoload 阶段扫描了不该扫的目录，比如项目根目录下误放了 logs/、storage/、node_modules/，或 composer.json 的 autoload 配置里写了 "psr-4": {"App\": "app/", "Tests\": "tests/", "Dist\": "dist/"} —— 后者会让 Composer 去遍历整个 dist/ 目录，哪怕里面全是压缩包或构建产物。
- 先运行
composer dump-autoload --no-scripts单独测试 autoload 阶段 - 检查
composer.json的autoload和autoload-dev字段，删掉非 PHP 源码路径 - 确认
vendor/外没有巨型 JSON/PHP 配置文件（比如导出的数据库 schema、前端打包产物） - 用
find . -type f -size +10M快速定位可疑大文件
Docker 或 CI 环境下内存不够的特殊表现
本地跑得通，CI 报错，常见于 Killed（无堆栈）、Process exited with code 137 或命令静默退出——这不是 Composer 错误，是系统 OOM killer 干掉了进程。因为容器内存上限（如 Docker Desktop 默认 2GB）比 PHP 的 memory_limit 更早触顶。
- GitHub Actions：用
composer/setup-phpAction 时，显式设memory-limit: 2G - GitLab CI：写成
php -d memory_limit=2G /usr/bin/composer install，别只写composer install - Docker：启动容器时加
--memory=4g，且确保宿主机有足够空闲内存 - Mac 上 Docker Desktop 内存配额默认仅 2GB，必须手动调高，否则
php -d memory_limit=3G也会失败
memory_limit、Composer 自身的 COMPOSER_MEMORY_LIMIT。少看一层，就可能卡在“明明设了 2G 却还是爆掉”的死循环里。 
