最稳解法是修改 Composer 所用 CLI 模式 PHP 的 php.ini 中 memory_limit 为 -1 或 2G，并重启终端验证；也可用 php -d memory_limit=-1 composer install 临时生效。
composer install 报 Allowed memory size exhausted 怎么办
直接改 php.ini 里的 memory_limit 是最稳的解法，但别只改全局值——Composer 运行时用的是 CLI 模式的 PHP，和 Web 服务器（比如 Apache/Nginx）用的不是同一个 php.ini 文件。
- 先确认 Composer 走的是哪个 PHP：运行
which php和php -i | grep "Loaded Configuration File"，看到的路径才是你要改的php.ini -
memory_limit改成-1（无限制）或2G都可以，但别写2048M——部分旧版 PHP 不识别带M的单位，只认2G或数字+M（如2048M在 PHP 7.2+ 才安全） - 改完必须重启终端（CLI 环境不会自动重载配置），再跑
php -m | grep composer验证不是必须的，但php -r "echo ini_get('memory_limit');"必须返回你设的值
不想动 php.ini？临时提内存有更干净的办法
用 php -d 覆盖单次运行的配置，不污染系统环境，适合 CI/CD 或多 PHP 版本共存场景。
- 执行
php -d memory_limit=-1 /usr/bin/composer install（路径以which composer为准） - 如果提示
command not found: composer，说明是用curl -sS https://getcomposer.org/installer | php下载的本地composer.phar，那就用php -d memory_limit=-1 php composer.phar install - 注意：Windows 上 cmd 不支持单引号，得用双引号；PowerShell 里变量符号
$会冲突，建议切到 Git Bash 或 WSL
为什么 vendor 大了就爆内存？和 autoload 机制强相关
Composer 安装时要生成 vendor/autoload.php 和类映射（classmap），尤其是启用了 "optimize-autoloader": true 或运行了 composer dump-autoload -o，会扫描全部 PHP 文件构建索引——文件越多、嵌套越深，内存吃得越凶。
- 项目里如果有大量未使用的包（比如历史遗留的
require-dev），先composer remove xxx清掉再装 - 避免在
autoload.files里引入大文件（比如整个工具库的functions.php），它会在每次请求时无条件加载 - PHP 8.1+ 开始，
composer install --no-autoloader可跳过生成 autoload（适合只打包不运行的场景），但后续必须手动dump-autoload
CI 环境（GitHub Actions/GitLab CI）常见翻车点
CI 默认的 PHP 镜像往往把 memory_limit 锁死在 128M 或 256M，光改 php.ini 没用，因为容器启动后配置已固化。
立即学习“PHP免费学习笔记（深入）”；
- GitHub Actions 中，在
run步骤开头加一句echo "memory_limit = -1" >> $(php -r "echo php_ini_loaded_file();")，再执行 composer - GitLab CI 如果用的是
php:cli镜像，推荐直接用php -d memory_limit=-1 composer install，比 patch ini 更可靠 - 某些托管平台（如 Laravel Forge、Ploi）后台改了 Web 版 PHP 的
php.ini，但忘了 CLI 版——务必单独检查php -i | grep memory
真正卡住人的从来不是“怎么改内存”，而是没意识到 CLI 和 Web 的 PHP 配置是两套体系；改完不验证、不重启终端，或者在 CI 里只修了表层配置，这些细节比参数值本身更容易让问题反复出现。
