答案是内存不足导致依赖解析失败，应优先用php -d memory_limit=-1 composer update临时扩容或COMPOSER_MEMORY_LIMIT=2G精准控制，禁用dev依赖、跳过autoload生成，并确认使用CLI版php.ini配置。
Composer install/update 卡在 “Resolving packages” 并报 Allowed memory size exhausted
这是 Composer 在依赖解析阶段（尤其是 composer update 或首次 composer install）内存爆掉的典型表现，不是网络或镜像源问题，而是 PHP 进程被系统或 PHP 配置限死了内存。Composer 2.x 的 SAT 求解器对复杂依赖图非常吃内存，哪怕你机器有 8GB，PHP 默认 memory_limit=128M 也完全不够用。
- 先确认是否真由内存触发：运行
composer update -v，看到类似PHP Fatal error: Allowed memory size of 134217728 bytes exhausted就是它 - 临时绕过：加
-d memory_limit=-1强制不限制，例如php -d memory_limit=-1 /usr/bin/composer update - 别只改
php.ini里的memory_limit—— CLI 和 Web SAPI 的配置常是分开的，必须确认你用的是 CLI 版本的 php.ini（查路径：php -i | grep "Loaded Configuration File"） - 如果用 Docker，记得在
php:cli容器里也同步调大，光改宿主机没用
用 composer install --no-update + composer update --lock 跳过解析阶段
当你只是想装 lock 文件里已确定的版本（比如 CI 环境或部署机），根本不需要重新解析依赖树。强行跑 composer update 是最浪费内存的操作。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install --no-update只读取composer.lock并下载包，不触发依赖求解 - 若 lock 文件过期需更新但又不敢跑全量
update，可尝试composer update --lock：它只重写 lock 文件、不安装包，且跳过冲突检测，内存开销极小 - 注意：
--lock不会升级任何包，只同步composer.json中修改过的 require/require-dev 版本约束到 lock 文件中
禁用 Packagist 镜像或切回官方源反而更快？
很多人以为换国内镜像一定更快，但某些镜像（尤其非官方维护的）同步延迟高、元数据格式不规范，会导致 Composer 解析时反复校验、重试、回溯，实际更耗内存和时间。
- 临时切回官方源测试：设环境变量
COMPOSER_REPO_PACKAGIST=https://packagist.org再运行composer update -v - 阿里云镜像（
https://mirrors.aliyun.com/composer/）和腾讯云镜像目前稳定性较好；慎用某些小众镜像，它们可能把packages.json做了非标准分片或压缩 - 如果你项目里用了大量私有 VCS 包（如 GitHub private repo），Composer 会为每个仓库发起 Git 检查，这时内存压力主要来自进程 fork 和 IO，而非镜像本身——这种情况下，优先考虑
"preferred-install": "dist"和"fxp-asset": false（如不用 bower）
终极方案：用 COMPOSER_MEMORY_LIMIT 环境变量精准控制
比改 php.ini 更安全、更可复现的方式，是用 Composer 自带的内存控制机制。它会覆盖 PHP 的 memory_limit，且只作用于当前命令。
- 设为 2G：运行
COMPOSER_MEMORY_LIMIT=2G composer update - 设为无上限（慎用）：
COMPOSER_MEMORY_LIMIT=-1 - 这个变量只影响 Composer 主进程，不影响其调用的 git 或 zip 进程；如果仍失败，说明是子进程（比如 git clone 大仓库）卡住，那就得单独优化 Git 配置（如
git config --global core.packedGitLimit 0） - CI 脚本里务必显式设置该变量，否则不同 runner 的默认值可能差异极大（GitHub Actions 默认 1G，GitLab Runner 可能只有 512M）
memory_limit 直接限制，但会拖垮主进程的堆空间。 
