卡在Resolving dependencies本质是DNS解析失败或镜像域名配置错误，未发起HTTP请求；需用dig验证DNS、检查hosts文件、确保composer镜像配置完整且执行clear-cache。
卡在 Resolving dependencies 是 DNS 或镜像配置失效
这一步根本没发 HTTP 请求，只做域名解析（比如查 mirrors.aliyun.com 的 IP），所以改 http.timeout 或加代理完全无效。常见现象是命令停住、光标不动、无任何错误输出。
- 用
dig mirrors.aliyun.com @8.8.8.8验证 DNS 是否通；若超时或返回空，说明本地 DNS 被污染或不可用 - 检查
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）是否误把镜像域名指向了127.0.0.1 - 执行
composer config -g repo.packagist，输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；少斜杠、拼错repo.packagist（写成repos.packagist）、漏type字段都会导致静默失效 - 换源后必须运行
composer clear-cache，否则旧缓存仍会拉取失败地址
Downloading 卡住要同时调 process-timeout 和 http-basic-timeout
多仓库场景下（比如同时用了阿里镜像 + 私有 GitLab 包），Composer 会交替发起 HTTP 和 Git 请求。process-timeout 控制整个命令生命周期（含 git clone、unzip），而 http-basic-timeout 只管单次 HTTP GET（如下载 zip 包）。只调一个大概率还会超时。
- 全局设高阈值：
composer config -g process-timeout 1800且composer config -g http-basic-timeout 300 - 临时调试可用命令行参数：
composer update --timeout=1200 --http-basic-timeout=240（注意：后者仅 Composer 2.2+ 支持） - 私有 Git 仓库的超时由系统
git命令控制，需额外配：git config --global core.sshCommand "timeout 300 ssh"（Linux/macOS） - 避免镜像和私仓混配：镜像源只加速
type: composer包，对type: git或type: vcs无效；若项目里硬编码了repositories，优先级高于全局镜像，得手动清理
执行 post-install-cmd 时超时不是网络问题
多仓库项目常依赖自定义脚本（比如 Laravel 的 php artisan key:generate 或私有包的构建命令），一旦卡在这步，报错 The process timed out，根源几乎都在 PHP 进程本身，而非 Composer 网络层。
- 先手动运行脚本确认是否真卡住，例如：
php artisan key:generate --no-interaction - 检查 PHP 配置：
max_execution_time和memory_limit是否过低（尤其 Docker 容器默认限制严） - 某些脚本会触发 autoload 重生成，若 vendor 下有大量 symlink 或嵌套过深的包，
composer dump-autoload -o可能 I/O 阻塞；此时应单独执行并观察磁盘读写 - CI 环境中务必显式传
--no-interaction，否则交互式提示会无限等待
path 仓库和多源共存时缓存最顽固
当你既用了镜像源，又 require 了本地 path 仓库，Composer 会混合读取元数据——这时缓存不一致比普通超时更难排查。典型表现是：require 成功但代码没更新、新 tag 拉不到、autoload 找不到类。
-
path仓库必须在它自己的composer.json中声明"options": {"symlink": true}，否则 Composer 默认 copy，改源码毫无意义 - 验证 symlink 是否生效：
ls -la vendor/vendor/name（Linux/macOS）看是否有→符号；Windows 需管理员权限，Docker 需--cap-add=SYS_ADMIN - metadata 缓存藏在
~/.composer/cache/repo/https---*，比文件缓存更顽固；遇到 tag 不更新，直接删对应目录比clear-cache更彻底 - autoload 映射不会自动继承，必须运行
composer dump-autoload -o让主项目加载 path 仓库的真实路径
多仓库配置下，超时往往不是单一参数能解决的。DNS 解析、HTTP 下载、Git 克隆、脚本执行、autoload 生成、缓存层级——每个环节都可能卡住，且错误表现高度相似。最容易被忽略的是：镜像源只管公共包，私有仓库和 path 仓库走的是完全不同的通道，它们的超时机制、缓存策略、权限校验也彼此独立。
