composer metadata更新滞后本质是http请求失败，需检查镜像是否为https、tls配置是否正常、缓存是否手动清理，并用-vvv验证真实请求及状态码。
Composer 提示无法获取最新的 metadata 信息，本质是 HTTP 请求失败，不是包本身不存在或版本写错了；切换到 HTTPS 协议只是表象操作，真正要解决的是底层连接是否被降级、拦截或误配。
为什么 composer show 或 update 显示 “Reading from cache” 却不拉新 metadata
Composer 默认优先读本地缓存（如 ~/.composer/cache/repo/https---packagist.org/），如果缓存未过期或网络请求被跳过，就完全不会触发远程拉取。常见诱因：
- 镜像源配置为 HTTP（如旧版
http://mirrors.aliyun.com/composer/），而当前网络策略强制拦截非 HTTPS 流量 - 系统 curl 或 PHP 的 OpenSSL 配置不支持 SNI，导致访问 HTTPS 镜像时握手失败，但 Composer 没报明确错误，静默 fallback 到缓存
- 全局配置中残留了
repo.packagist的 HTTP 地址，覆盖了 HTTPS 默认行为
验证方式：运行 composer config -g repo.packagist，输出必须是以 https:// 开头的地址；若含 http://，立刻修正。
如何确认 metadata 请求是否真的走 HTTPS 并成功响应
加 -vvv 参数看真实请求链路，重点观察两处：
- 是否出现
Downloading https://...行（说明发起 HTTPS 请求） - 是否有
status code 200或304（而非000或超时）
如果看到 Failed to connect 或卡在 Resolving packagist.org...，问题不在 Composer，而在 DNS 或 TLS 层。此时换 HTTPS 源没用，得先跑 curl -I https://mirrors.aliyun.com/composer/packages.json 看是否通。
HTTP 镜像源被拦截后，只改协议还不够
国内主流镜像（阿里云、清华、腾讯）已全站 HTTPS，但部分老旧文档或脚本仍硬编码 HTTP 地址。即使你手动设成 HTTPS，以下情况仍会失效：
- 项目级
composer.json中定义了"repositories"，它的优先级高于全局配置，必须检查并同步更新 -
composer clear-cache后，缓存目录名仍带旧协议（如http---mirrors...），Composer 可能继续读它——需手动删掉整个~/.composer/cache/repo/下对应子目录 - 某些 CI 环境（如 GitHub Actions）默认禁用 TLS 1.3 或使用精简 OpenSSL，导致与新版镜像握手失败，需显式设置
COMPOSER_DISABLE_TLS=0并确保 PHP 编译时启用了openssl
metadata 更新滞后，但你又不能等镜像同步怎么办
镜像源同步有延迟（通常 5–30 分钟），如果你急需某个刚发布的版本，临时切回官方源是最直接方案：
- 先清缓存：
composer clear-cache - 临时取消镜像：
composer config --unset repos.packagist - 强制重拉：
composer update --no-cache --dry-run（加--dry-run避免实际安装）
注意：别在生产 CI 中长期用官方源，国内节点不稳定；更稳妥的做法是用 composer show -a vendor/package 查可用版本，确认目标版本确实已发布，再决定是否切源。
metadata 不是“数据”，而是 Composer 的决策依据；它一旦陈旧，所有依赖解析、版本比较、冲突检测都会基于错误前提。很多人删 vendor、重装 Composer，却漏掉清缓存或验证镜像协议——这才是最常被跳过的一步。
