Composer 卡住90%是假死，先用 composer update -vvv 查看最后一行定位卡点：镜像源连不上、依赖解析慢、下载慢、Git 克隆失败等，再换阿里云镜像、清缓存、调超时、强制 --prefer-dist。
Composer 安装或 update 卡住不动，90% 不是真死机，而是卡在下载、解析或 Git 克隆环节——先别 Ctrl+C，用 composer update -vvv 看清最后一行输出，再对症下药。
看日志：定位卡在哪个阶段最准
假死 ≠ 崩溃，只是没输出。加详细参数才能知道它到底在干啥：
-
composer update -v：显示基本流程（如“Loading repository”、“Resolving dependencies”） -
composer update -vv：暴露 HTTP 请求和 Git 命令（看到Cloning into 'xxx'就是卡在克隆） -
composer update -vvv：打印完整堆栈和原始命令，能精准定位到具体包或 URL
常见卡点含义：
- 停在
Loading composer repositories with package information→ 镜像源连不上，或元数据拉取超时 - 停在
Resolving dependencies through SAT→ 依赖约束太复杂，Solver 正在暴力尝试（尤其含多个dev-master或模糊版本） - 停在
Downloading https://.../dist/xxx.zip→ 网络慢或镜像失效 - 停在
Cloning into '/tmp/xxx'→ SSH 密钥问题、私有仓库不可达，或 Git 仓库过大
换镜像：国内用户最该优先做的一步
packagist.org 在国内直连极不稳定，阿里云、腾讯云等镜像已全量同步且 HTTPS 可靠，切完立竿见影：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：
composer diagnose | grep "Repo packagist.org"
输出应为 Repo packagist.org: https://mirrors.aliyun.com/composer/，不是 https://packagist.org。若仍走原站，检查是否被项目级配置覆盖（composer config repo.packagist 查当前项目设置）。
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
注意坑点：
-
phpcomposer.com镜像已于 2024 年底停止服务，勿再使用 - 某些 CI 环境（如 GitHub Actions）需在每步命令前重设镜像，或改用
COMPOSER_REPO_PACKAGIST环境变量
清缓存 & 调超时：解决“看起来卡住”的底层原因
缓存损坏、磁盘满、超时阈值过低，都会导致无响应假象：
- 清空所有缓存：
composer clear-cache（等价于删掉~/.composer/cache目录） - 延长单次操作等待上限：
composer config -g process-timeout 3000（单位秒，默认仅 300） - 跳过平台检查（仅调试用）：
composer update --ignore-platform-reqs，避免因缺ext-zip等扩展反复校验卡死
若 composer.lock 已存在且你只想重装依赖（非升级），用 composer install 比 update 更轻量、更稳定；若 lock 文件损坏，可先 rm composer.lock 再 composer install 重建。
绕开 Git 克隆：强制走 dist 包安装
开发分支（dev-main、dev-develop）默认触发 git clone，而国内访问 GitHub 极易卡在 Cloning into。强制走压缩包分发能避开所有 Git 问题：
- 临时生效：
composer update --prefer-dist - 项目级永久设置：
composer config prefer-dist true - 全局永久设置：
composer config -g prefer-dist true
但注意：若 composer.json 中某包明确指定 "type": "package" 或引用未打 tag 的私有 Git 分支，--prefer-dist 可能失效，此时需确认该包是否真有必要用 dev 分支，或手动发布 stable tag。
真正卡住的难点往往藏在细节里：比如镜像配置被项目级 config 覆盖、process-timeout 改了但没加 -g 全局生效、或是某个 post-update-cmd 脚本里调用了阻塞的 shell 命令。每次卡住，先 -vvv 看最后一行，比盲目重试快十倍。
