最直接有效的解法是php -d memory_limit=-1 composer install，因Composer本质是PHP脚本，内存受限于PHP进程启动时的memory_limit，该参数在命令前加可临时绕过限制，不改配置、不重启服务。
php -d memory_limit=-1 是最直接有效的命令行解法
Composer install 报 Allowed memory size exhausted，本质是 PHP CLI 进程启动时被 memory_limit 卡住，不是 Composer 自己吃内存。临时绕过限制只需在命令前加 php -d memory_limit=-1：
-
php -d memory_limit=-1 composer install（Windows / macOS / Linux 通用） -
php -d memory_limit=2G composer install（生产环境更稳妥，避免 -1 触发 OOM killer） - 别写
2048M——某些 PHP 版本对单位解析不一致，2G更可靠
为什么改 composer.json 的 memory-limit 没用
composer config --global memory-limit -1 或往 composer.json 写 "memory-limit": "-1" 几乎无效。因为 Composer 启动流程是：PHP 解释器先读 memory_limit ini 值 → 超限就直接崩溃 → 根本没机会执行到 Composer 自己的配置读取逻辑。
- 运行
php -r "echo ini_get('memory_limit');"查当前值，如果是128M或512M，那 Composer 一定卡在这一步 -
composer config只是存个字段，它不改 PHP 层限制，也不重启 PHP 进程 - 某些 CI 环境（如 GitHub Actions 默认 Ubuntu）里，
memory_limit被设为-1，但 cgroup 实际限制了可用内存，此时 Composer 会被系统直接 kill，错误日志里可能连 PHP 错误都不显示
修改 php.ini 是长期方案，但要注意作用域
如果频繁遇到该问题，可改 CLI 专用的 php.ini，但必须确认改的是对的那个文件：
- 先运行
php --ini，看Loaded Configuration File路径，别只改 Apache/Nginx 下的配置 - 编辑该文件，把
memory_limit = 512M改成memory_limit = 2G（注意单位统一用G） - 改完不用重启 Web 服务，CLI 下生效立即可见；但 Web SAPI（如 Apache mod_php）仍需重启对应服务
- Docker 环境中，
docker exec -it app php --ini才是真相，宿主机改了没用
CI/CD 和 Docker 中容易忽略的细节
本地能跑，CI 上失败，大概率是环境隔离导致的配置错位：
- GitHub Actions 用
composer/setup-phpAction 时，必须显式传memory-limit: 2G参数，否则走默认 128M - GitLab CI 中，若用自定义 PHP 镜像，确保
php --ini输出的配置路径可写，且memory_limit已调高 - Alpine + PHP 8.2 组合下，
opcache.preload若启用，会提前加载大量类定义，让 Composer 内存峰值翻倍；临时禁用：php -d opcache.enable=0 -d memory_limit=-1 composer install - CI 中优先用
composer install --no-dev，dev 依赖常占一半以上内存，尤其带 PHPStan、Pest 的项目
memory_limit，不是 Composer 自己的配置项；而最易被忽略的，是 CLI 和 Web、宿主机和容器、不同 PHP SAPI 之间配置完全不共享这个事实。 
