直接提高php内存限制最有效：用php -d memory_limit=-1 composer install（linux/macos）或php -d memory_limit=2g composer install（windows），因composer解析依赖和生成autoload时内存消耗大，而set_time_limit无效、php.ini修改不推荐。
composer install 内存不足直接崩溃
默认情况下，composer 会继承 PHP 的 memory_limit 设置（通常是 128M 或 256M），但现代项目依赖多、自动加载映射大，很容易在 composer install 或 update 时触发 Allowed memory size exhausted 错误。这不是 Composer 本身的问题，而是它在解析依赖树、生成 autoloader 和写锁文件时吃内存太猛。
最直接有效的办法是临时提高 PHP 内存上限——不是改 php.ini，而是命令行里指定：
- 运行
php -d memory_limit=-1 /usr/bin/composer install（-1表示无限制，Linux/macOS 下常用） - Windows 用户可用
php -d memory_limit=2G composer install（注意路径和引号问题） - 如果用的是
composer.phar直接执行，确保前面的php -d参数在composer.phar之前，顺序错了不生效
为什么 set_time_limit(0) 没用，而 memory_limit 必须显式设
set_time_limit 是 PHP 脚本运行时函数，对 CLI 模式下由 php 进程启动的 composer 不起作用——因为 composer 是独立 Phar 应用，它的超时控制在内部，你改不了。但内存限制不同：php -d memory_limit 是启动参数，在进程初始化阶段就生效，能覆盖所有后续操作。
- 别在
composer.json里加配置项试图调内存——没这个字段 - 别改系统级
php.ini：会影响其他 CLI 工具，且多人协作时不可靠 - CI 环境（如 GitHub Actions）建议统一用
php -d memory_limit=2G composer install，避免因基础镜像默认值低而失败
vendor/autoload.php 生成慢或失败也可能是内存问题
很多人只关注 install 报错，却忽略后续 autoload dump 阶段也会爆内存——尤其当项目用了大量 psr-4 映射或自定义加载逻辑时。Composer 在生成优化后的 autoload_static.php 时需要遍历全部类文件，这时候内存压力反而更大。
- 执行
composer dump-autoload --optimize前，同样要带php -d memory_limit=-1 - 如果只是开发调试，去掉
--optimize能显著降低内存峰值（但性能略差） - 检查
composer.json中是否有过度宽泛的autoload/psr-4映射（比如"": "src/"却包含测试文件或大资源目录），这会让扫描范围失控
长期项目该不该调高默认 memory_limit
可以，但得看场景。本地开发机内存充足，把 CLI 模式的 memory_limit 设成 1G 或 2G 很稳妥；但服务器部署脚本或 Dockerfile 里硬编码 -1 就有风险——万一某个坏包触发无限循环，可能把整台机器拖垮。
- 推荐做法：在项目根目录写个
run-composer.sh，内容为php -d memory_limit=1536M $(which composer) "$@"，然后所有人走这个封装 - Docker 构建中，用
RUN php -d memory_limit=2G composer install --no-interaction，别省掉-d - 真正难搞的是某些共享主机或老旧 CI 平台，连
php -d都被禁用——这时只能删vendor后用--no-autoloader分步装，再手动dump-autoload
内存限制不是越大越好，但不够一定出事。关键在匹配实际依赖规模，而不是盲目堆数字。
