composer卡在“resolving dependencies”是sat求解器本地穷举版本组合导致内存溢出，与网络无关；根本原因是php memory_limit过低、xdebug启用、约束过宽或lock文件残留，需用php -d memory_limit=2g配合--no-dev、--prefer-dist等参数精准调优。
CI中Composer内存耗尽，换镜像源本身不解决问题——它只加速下载，而爆内存发生在“Resolving dependencies”阶段，这个阶段根本不走网络。
为什么换镜像后还是卡在 Resolving dependencies
这个阶段是 Composer 依赖求解器（SAT solver）在本地解析 composer.json 中所有约束条件，生成满足全部要求的版本组合。它完全离线，但极其吃内存和 CPU。常见诱因包括：
- PHP
memory_limit过低（如默认 128M），solver 尝试回溯数千种组合时直接 OOM - 启用了
xdebug（运行php -v可确认），会让 solver 慢 5–10 倍、内存占用翻倍 -
composer.json中存在宽泛约束，例如"monolog/monolog": "^1.0 || ^2.0"，极大扩张搜索空间 - 项目残留已下线包的
composer.lock条目，触发降级查找逻辑
CI里真正有效的内存调优组合
别只改镜像，要在命令层面切断高内存路径：
- 显式用
php -d memory_limit=2G调用，避免 shell wrapper 忽略参数（which composer输出/usr/bin/composer就是 wrapper） - 加
--no-dev：跳过require-dev的安装，更重要的是——它让 solver 不再考虑 dev 包的约束关系 - 加
--prefer-dist：减少临时解压和 Git 克隆开销，间接降低内存峰值压力 - 加
--no-autoloader --no-scripts：把 autoload 生成和脚本执行拆到安装后单独跑，避免挤在同一进程 - 禁用 xdebug：
php -d xdebug.mode=off $(which composer)或在 CI 配置中提前关闭
哪些操作看似省事实则危险
COMPOSER_MEMORY_LIMIT=-1 环境变量在 CI 中容易误用：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它**不绕过 PHP 底层
memory_limit**，进程在分配第 129MB 时就被 kill，Composer 根本读不到这个变量 - Docker 或 GitHub Actions runner 若本身内存只有 2GB，设 -1 可能导致整个容器被 OOM killer 干掉
- CI 脚本里写
composer install却没指定 php 解释器，等于白设
真正可靠的做法，是在每条命令前都带上 php -d memory_limit=2G，并确保调用的是 composer.phar 或绝对路径。
锁文件残留是静默杀手
CI 中反复失败，尤其是从旧分支切过来后，大概率是 composer.lock 里还存着已废弃或版本冲突的包引用。Solver 会为这些条目反复尝试兼容路径，直到超时或爆内存。
- 开发环境可删干净再装：
rm -rf vendor/ composer.lock && composer install --no-interaction - CI 中慎用全删（影响缓存命中），改用
composer install --no-interaction --no-cache强制忽略本地 lock 缓存 - 长期建议在
composer.json里收紧约束，比如把"^1.0"改成"^1.25"，或用composer why-not vendor/package:2.0定位拖慢 solver 的包
Resolving dependencies 阶段没有“网络优化”这回事，所有调优必须落在 PHP 进程控制、依赖结构收敛、以及 solver 输入精简上。
