最常用方式是php -d memory_limit=-1 composer install，因它能绕过PHP默认内存限制且不改配置文件；-1表示不限制，适合调试和CI临时修复，但需注意Windows PowerShell需加引号、顺序不可错、单位须大写。
php -d memory_limit=-1 composer install 为什么最常用
因为这是唯一能绕过 PHP 默认 memory_limit（通常是 128M 或 256M）并立即生效的方式，且不改动任何配置文件。Composer 在解析依赖树、下载元数据、生成 autoload 映射时会大量读取 JSON、遍历包、加载类定义——这些操作全在单个 PHP 进程里完成，memory_limit 就是它的天花板。
常见错误现象：Allowed memory size of 134217728 bytes exhausted（即 128MB），说明 PHP 进程被硬性截断。
-
php -d memory_limit=-1 composer install中的-1表示不限制，适合本地调试和 CI 临时修复 - 若需设具体值，必须用大写单位：
php -d memory_limit=2G（小写g会被忽略） - Windows PowerShell 用户要加引号：
php -d "memory_limit=-1"，否则-1可能被 CMD 截断 - 顺序不能错：
php -d必须在composer命令之前；如果用composer.phar，得写成php -d memory_limit=-1 composer.phar install
COMPOSER_MEMORY_LIMIT 环境变量到底管不管用
它有用，但作用范围很窄：只影响 Composer 自身的内存预分配逻辑（比如依赖解析循环是否提前中断），**不能突破 PHP 底层的 memory_limit 限制**。也就是说，即使设了 COMPOSER_MEMORY_LIMIT=-1，只要 PHP 进程本身被 memory_limit=128M 卡住，照样报错。
使用场景：作为“二次防护”，避免某个插件或坏包触发无限递归导致内存缓慢爬升后失控。
-
COMPOSER_MEMORY_LIMIT=1536M composer install是较稳妥的 CI 设置，比-1更可控 - Linux/macOS：直接 export 或前置设置；Windows CMD 用
set COMPOSER_MEMORY_LIMIT=1536M；PowerShell 用$env:COMPOSER_MEMORY_LIMIT="1536M" - 它优先级高于
php.ini，但低于php -d memory_limit，所以两者共存时以后者为准
composer install 和 composer update 的内存差异在哪
composer update 是真正的内存杀手，而 composer install 理论上轻量得多——但它也可能崩，关键看 composer.lock 是否“干净”。
常见错误现象：明明只跑 install 却爆内存，结果发现 composer.lock 文件超过 5MB，里面塞满了 dev-master 提交哈希、嵌套 package-versions 映射、废弃包残留记录。
-
composer update要重新执行 SAT 算法求解整个依赖图谱，下载所有包的composer.json元数据，内存峰值常达install的 3–5 倍 -
composer install --no-dev -o（跳过开发依赖 + 优化自动加载）可降低 40%+ 内存占用 - 生产环境禁止直接运行
update；所有更新必须在开发机完成，提交新的composer.lock后再部署 - CI 中若缓存了
vendor/但没同步composer.lock，下次install实际会退化为update，这是隐藏雷区
Docker / CI 环境下容易被忽略的三件事
很多人在容器或 GitHub Actions 里加了 php -d memory_limit=-1 还是失败，问题往往不在 PHP 配置本身。
性能与兼容性影响：Docker 容器有独立的 cgroup 内存限制，PHP 层面的无限制无法突破宿主机或 --memory=512m 的硬约束；GitHub Actions 的 ubuntu-latest 默认 PHP 是 128M，且不加载用户自定义 php.ini。
- 检查容器内存上限：
docker run --memory=2g your-image php -r "echo ini_get('memory_limit');"，确保底层资源够 - CI 中不要依赖全局
php.ini，统一用命令行参数：php -d memory_limit=2G $(which composer) install --no-dev -o - 某些共享主机禁用
-d参数，此时唯一办法是提前在本地生成好composer.lock和vendor/，上传后只运行composer install（不解析依赖）
真正难处理的不是内存数字本身，而是当 php -d memory_limit=4G 仍失败时——那大概率是 composer.lock 结构畸形、autoload files 列表爆炸、或某个废弃包的 composer.json 触发了 Composer v1 的递归 bug。这时候调内存只是掩耳盗铃。
