composer安装依赖爆内存主因是php解析依赖图时内存不足，需用php -d memory_limit=2g命令临时调高限制，并确认cli模式php.ini路径；composer_memory_limit环境变量不能突破php底层限制。
Composer 在安装依赖时爆内存，根本不是网络或源的问题，而是 PHP 进程在解析依赖图（SAT 算法）阶段把所有包的版本约束、autoload 映射、锁文件元数据全加载进内存，直接撑爆 memory_limit。卡在 Resolving dependencies 就是典型信号，错误末尾常带 Allowed memory size of XXXXXX bytes exhausted。
为什么 php.ini 改了也没用
你改的可能是 Apache 或 Nginx 加载的 php.ini，而 CLI 模式下 Composer 根本不读它。运行 php --ini 查看 Loaded Configuration File 路径，确认是否对应 CLI 配置。更稳妥的做法是命令行临时覆盖：
-
php -d memory_limit=2G composer install（推荐，Linux/macOS/Windows CMD 均可用） -
php -d memory_limit=-1 composer install（仅限调试或 CI，生产环境禁用） - 如果用的是
./composer.phar，必须写成php -d memory_limit=2G ./composer.phar install
COMPOSER_MEMORY_LIMIT 环境变量为什么有时失效
这个变量是 Composer 自己识别的，但它只控制内部预分配逻辑，**不突破 PHP 底层的 memory_limit**。也就是说，如果 PHP 进程本身已被 memory_limit=128M 卡死，Composer 根本没机会执行到读取该变量的代码。
所以单独设 COMPOSER_MEMORY_LIMIT=2G 是无效的，必须搭配 php -d 才可靠：
-
php -d memory_limit=3G COMPOSER_MEMORY_LIMIT=2G composer update（双保险，尤其适合 monorepo） - Windows PowerShell 用户注意语法：
$env:COMPOSER_MEMORY_LIMIT="2G"，等号前后不能有空格 - CI/CD 中建议显式写在
env:块里，别依赖 runner 默认值
哪些参数能真正减内存，而不是硬扛
光提内存是治标。很多项目爆内存，是因为在跑根本不需要的操作。以下参数能从流程上砍掉大块内存开销：
-
--no-dev：跳过require-dev的解析和安装，内存占用常降 40%~60%，上线部署必加 -
--prefer-dist：强制走 zip 包而非 git clone，避免 git 进程吃内存（默认已开启，但显式写上更明确） -
--optimize-autoloader（或-o）：生成扁平 classmap，降低 dump 阶段内存峰值 -
--no-plugins：禁用钩子型插件（如composer-unused），它们会在每个包安装后触发，放大串行延迟
大型项目和 Monorepo 的特殊处理
Monorepo 场景下，Composer 默认会重复解析 workspace 内几十个包的 composer.json，叠加 symlink 扫描，I/O 和逻辑开销陡增。这时单靠提内存意义不大：
- 根目录
composer.json中避免用"*"或模糊约束引用内部包，否则拒绝复用已安装 symlink - 日常开发进子包目录执行：
cd packages/utils && composer install --no-install --no-autoloader，只生成 autoload，不下载任何包 - CI 构建单个包时，才进对应目录执行完整
composer install - 确认关闭无用插件：
"fxp-asset": false（若未用 bower/npm-asset），否则额外发起大量 HTTP 请求
真正关键的点常被忽略：Composer 解析阶段的内存消耗和 PHP 的 OPcache 是否启用强相关。CLI 模式下 OPcache 默认可能被关掉（尤其某些 Docker 镜像），导致每次都要重新编译 Composer 自身代码。务必加 php -d opcache.enable_cli=1 再跑，效果立现。
