确认是网络链路问题而非Composer故障：执行curl -I https://packagist.org/packages.json，若返回200且Content-Type为application/json则通；超时或“Could not resolve host”需查DNS；403或空响应多因防火墙拦截，应切阿里云镜像并清除缓存、修正URL末尾斜杠、检查项目级repositories是否覆盖全局配置。
Composer 显示“服务不可用”类报错（如 Could not fetch packagist.org、Connection refused、Operation timed out、卡在 Loading composer repositories）——基本不是 Packagist 官方宕机，而是你本地到它的链路被阻断。官方服务近 3 年无全局性中断记录，这类报错 90% 源于 DNS、TLS 握手、中间代理或镜像配置失效。
怎么确认是网络链路问题而不是 Composer 坏了？
直接绕过 Composer 走一次原始请求，验证底层连通性：
- 执行
curl -I https://packagist.org/packages.json：若返回HTTP/2 200且有Content-Type: application/json，说明网络通、TLS 正常、DNS 解析正确 - 若超时或报
Could not resolve host，立刻查cat /etc/resolv.conf（Linux/macOS）或ipconfig /all（Windows）看 DNS 是否被污染或设为 127.0.0.1 - 若返回
HTTP/2 403或空响应体，大概率是公司防火墙或校园网拦截了packagist.org域名（非 IP），需切镜像
阿里云镜像为什么切了还报错？
镜像切换后仍失败，常见三个静默陷阱：
-
composer config -g repo.packagist显示已设置，但项目级composer.json里有"repositories"数组——它会完全屏蔽全局镜像，必须删掉或显式补上兜底项：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/", "packagist": false} - 切完没清缓存：
composer clear-cache必须执行，否则 Composer 仍尝试用旧失败记录重试 - 镜像 URL 少了末尾
/：正确是https://mirrors.aliyun.com/composer/，写成https://mirrors.aliyun.com/composer会导致 301 重定向失败（尤其在某些 cURL 版本下）
报错里出现 “file could not be downloaded” 怎么快速定位真实失败点？
加 -vvv 是唯一可靠方式，它会打印每条 cURL 请求的原始 URL 和响应头：
- 运行
composer update -vvv 2>&1 | grep "GET https"，看最后发出的是哪个地址——如果是https://packagist.org/...，说明镜像没生效；如果是https://mirrors.aliyun.com/composer/...却仍失败，就去阿里云镜像站页面手动打开那个 URL 验证是否可访问 - 若看到
zlib_decode(): data error，说明中间 CDN 或代理损坏了 gzip 压缩流，临时禁用压缩：composer config -g http.ssl.curl.options."10066" 0（关闭 CURLOPT_ENCODING） - 若卡在
Resolving dependencies through SAT后无输出，不是网络问题，是依赖逻辑冲突，应立即停手改用composer why-not
真正容易被忽略的是：Packagist 官方服务本身极稳定，但国内用户几乎从不直连它。一旦报“服务不可用”，第一反应不该是查官网状态页，而是检查本地 DNS、cURL 版本、镜像配置层级和缓存是否干净——这四步走完，80% 的所谓“服务不可用”就消失了。
