Composer 进程崩溃主因是依赖解析、元数据加载和 autoload 生成三高内存操作挤在单进程内，99%为内存耗尽；ulimit 限制、Xdebug、Windows 长路径、锁文件过大及错误配置（如 autoload.files 或 psr-4 误配）均加剧问题，--no-dev --no-plugins --no-scripts -o 组合最有效。
Composer 进程崩溃不是 PHP 本身太弱，而是它把依赖解析、元数据加载和 autoload 生成这三个高内存操作全塞进单个 PHP 进程里执行；卡在 Resolving dependencies 或 Loading composer repositories 时，99% 是内存耗尽，不是网络或磁盘问题。
为什么 php -d memory_limit=-1 还报错
加了不限制内存仍失败，说明问题已溢出 PHP 层面：
-
ulimit -v或ulimit -m在容器/CI 中设得太低，PHP 进程连申请内存的机会都没有 - Composer 2.2+ 自带隐式保护：当求解超 5000 个版本组合时会主动中止，此时再提内存无效
- Xdebug 启用状态下，内存消耗常翻倍；真实测试环境应加
php -d xdebug.mode=off -d memory_limit=-1 - Windows 下未启用长路径支持，解压 ZIP 时反复创建失败临时文件，间接耗尽内存
composer install 和 composer update 的内存行为差异
名字有误导性——install 不一定比 update 轻量，关键看 composer.lock 是否“干净”：
-
composer update必然重跑 SAT 求解器，下载全部元数据，是标准内存杀手；生产环境禁止直接运行 -
composer install理论上只读 lock 文件，但若该文件体积超 5MB（常见于含大量dev-master提交哈希、嵌套package-versions），解析过程反而更耗内存 - 锁文件过大时，
composer install --no-dev可立竿见影降内存，前提是确认当前不需要require-dev中的包
真正能砍掉内存峰值的参数组合
这些参数跳过高开销环节，比硬提内存更治本：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：跳过require-dev解析，降内存 40%~60%，上线部署必须加 -
--optimize-autoloader（或-o）：生成扁平classmap，避免运行时递归扫描目录 -
--no-plugins：禁用全局插件（如hirak/prestissimo），它们会在每个包安装后触发额外 autoload 注册 -
--no-scripts：跳过post-install-cmd等脚本，防止脚本内再次require 'vendor/autoload.php'叠加注册
组合使用效果最强：php -d memory_limit=1G composer install --no-dev --no-plugins --no-scripts -o
容易被忽略的底层陷阱
有些配置看似合理，实则让内存问题雪上加霜：
- 在
autoload.files里引入大体积全局函数文件（比如含数百个辅助函数的helpers.php），会让dump-autoload阶段反复读取和解析 - 误配
psr-4映射到整个vendor/目录，让 Composer 扫描所有第三方代码——这不会报错，但会让内存峰值翻倍 - 某些 CI 平台（如 GitLab Runner）默认禁用
-d参数，此时必须改用COMPOSER_MEMORY_LIMIT=-1并配合--no-dev等参数才有效
最危险的是删掉 vendor/ 和 composer.lock 后直接跑 composer update：等于强制全量重算 + 下载 + 解压，是最烧内存的操作。
