Composer命令卡住通常因网络、配置或权限问题：卡在“Loading composer repositories”多为DNS/TLS连接失败，需测curl、禁IPv6或换镜像源；卡在“Resolving dependencies”常因版本约束过宽或PHP版本不匹配；权限问题如proc_open禁用、vendor归属错误也导致假死；务必加-vvv参数定位真实错误。
Composer命令执行无响应，大概率卡在“Loading composer repositories”或“Resolving dependencies”阶段，而不是程序真死掉了——它在等网络、等锁、等 PHP 函数返回，或被权限/配置 silently block 住。
卡在 Loading composer repositories 是 DNS 或 TLS 连不上
这一步根本没开始解析依赖，纯粹是连不上元数据源。日志停在这儿，composer install 就会一直转圈不报错。
- 先用
curl -I https://packagist.org/packages.json测试：返回SSL connect error是 TLS 握手失败；超时或卡住是 DNS 污染或 IPv6 干扰 - 强制走 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS）或set CURL_IPRESOLVE=4 && composer install（Windows CMD） - 临时禁用 IPv6：
COMPOSER_NO_IPV6=1 composer install - 验证 DNS：
nslookup packagist.org，失败就改/etc/resolv.conf（Linux/macOS）或网络适配器 DNS（Windows）加8.8.8.8
镜像配置写错导致静默 fallback 到官方源
你以为换源成功了，其实 composer config -g repo.packagist 输出是空、null 或还是 https://repo.packagist.org，那它就在默默连国外源，卡得理直气壮。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须三要素齐全：
repo.packagist（单数，不能是repos）、composer（type 值显式写出）、URL 以/结尾（https://mirrors.aliyun.com/composer/✅） - 验证是否生效：
composer config -g repo.packagist输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 若仍看到
packagist.org在日志里，立刻检查项目级配置是否覆盖全局：composer config repo.packagist（无-g） - 清缓存：
composer clear-cache，再删composer.lock和vendor/重来
卡在 Resolving dependencies 要看约束是否过宽
换源只加速下载，不解决依赖求解慢。如果 composer install -vvv 卡在 Resolving dependencies 超 10 秒，基本是 composer.json 里写了太松的版本范围，比如 "^1.0 || ^2.0 || ^3.0" 或直接 "*"，让求解器穷举组合。
- 收紧版本约束：把
"*"改成具体小版本，如"3.4.5"；把宽泛的"^2.0"改成"2.4.*" - 用
composer prohibits vendor/package查冲突源头（比如某个包强制要求php: >=8.2，而你 CLI 是 8.1） - 临时跳过平台检查：
composer install --ignore-platform-reqs（仅调试用，别提交） - 确认
php -v和composer show php版本一致，否则求解器反复回溯
权限或函数禁用导致进程挂起
尤其在虚拟主机、Docker 或 CI 环境下，proc_open() 被禁用、vendor/ 归属为 root、或缓存目录不可写，都会让命令看起来“没反应”，实则卡在系统调用上。
- 检查
vendor/所有权：ls -ld vendor/，若第一列含root root，运行sudo chown -R $USER:$USER vendor/ - 查全局缓存归属：
ls -ld $(composer config --global cache-dir)，同样用chown修复 - 虚拟主机常见问题：
exec、proc_open被禁用 → 改用composer install --no-scripts --no-plugins --optimize-autoloader - Docker 中 UID 不匹配：宿主机 UID 是 1000，容器以 root（UID 0）运行 → 启动时加
user:1000，或修复时用数字 UID：sudo chown -R 1000:1000 vendor/
最易被忽略的是：没有 -vvv 就判断“无响应”。很多真实错误（如 Fatal error: Uncaught Error:、Class not found）只在 -vvv 下透出 stderr。卡住时第一反应不是重启，而是加 -vvv 看最后一行输出什么。
