换镜像源比调超时参数更有效，90%的“慢”和“超时”源于网络连接层问题；应优先使用阿里云或腾讯云镜像，验证并确保配置生效，配合清缓存与网络诊断，而非盲目增加timeout。

换镜像源比调超时参数更有效，90% 的“慢”和“超时”根本不是 Composer 自身问题，而是卡在了网络连接层——比如 DNS 解析失败、TLS 握手卡住、或镜像源响应延迟。盲目加 --timeout=3600 只会让命令 hang 得更久，却掩盖了真实瓶颈。

确认当前用的是哪个镜像源

很多人以为自己切了国内源，其实配置没生效或被覆盖。执行以下命令验证：

composer config -g repos.packagist

正确输出应类似：

{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}

如果看到 packagist.org 或空值，说明镜像未生效。常见原因包括：

• 误用了已停用的旧地址（如 https://packagist.phpcomposer.com）
• 项目级配置覆盖了全局配置（检查项目 composer.json 里的 repositories 字段）
• CI 环境中 COMPOSER_HOME 指向了另一个配置目录

优先用阿里云或腾讯云镜像，别碰 Laravel China

Laravel China 镜像（https://packagist.laravel-china.org）自 2025 年底起已不稳定，频繁返回 502/503；而阿里云和腾讯云镜像同步及时、节点分布广、HTTPS 响应快。设置方式如下：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 全局生效：composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/
• 仅当前项目：composer config repos.packagist composer https://mirrors.aliyun.com/composer/
• 临时单次使用（不改配置）：composer update --repository=https://mirrors.aliyun.com/composer/

设完立刻清缓存：composer clear-cache，否则旧包仍可能从旧源拉取。

process-timeout 不是 HTTP 超时，别和 curl error 28 混淆

当你看到错误里带 cURL error 28（如 Operation timed out after 300000 milliseconds），说明是底层网络连接超时，process-timeout 完全不生效。此时该做的不是加 timeout，而是：

• 手动测连通性：curl -v https://mirrors.aliyun.com/composer/packages.json，看卡在 DNS、TCP 还是 TLS
• 若卡在 TLS，检查系统时间是否同步（尤其 WSL/Docker）：date；不一致会导致证书验证失败
• 公司网络下确认 HTTP_PROXY/HTTPS_PROXY 是否设对，旧版 Composer 需额外配 http.sslcafile
• 临时关闭 HTTPS 验证（仅调试用）：composer config -g secure-http false

CI/CD 中超时反复失败，光加 timeout 不够

GitHub Actions、GitLab CI 等环境常因 DNS 不稳、并发连接数高、或内存不足导致失败。不能只靠 --timeout=1200 硬扛，要组合优化：

• 显式指定 DNS：run: echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf（GitHub Actions 不支持，改用 --dns 参数或 action setup-php 的 cache: composer）
• 禁用 dev 包：composer install --no-dev --prefer-dist --optimize-autoloader
• 避免首次安装卡死：提前在 CI 缓存 ~/.composer/cache 目录
• 跳过平台检查（仅限构建阶段）：--ignore-platform-reqs，但上线前必须回归验证

真正难排查的是那种“没报错、没日志、就卡住”的情况——大概率是 DNS 解析失败后 Composer 在默默重试 5 次，每次等 60 秒。这时候加 -vvv 看最后几行输出，比盲目调 timeout 有用得多。