signature verification failed的根本原因是本地环境与镜像源之间的时间、证书或元数据信任链断开，须按顺序排查系统时间偏差＞5分钟、ca证书过期、镜像停服或未同步新签名三者之一，清缓存完全无效。
“Signature verification failed”不是缓存问题，清缓存完全无效——根本原因是本地环境无法验证镜像返回的 packages.json 签名，必须先修时间、证书、镜像三者之一的断点。
怎么一眼分清是签名失败还是哈希不匹配
看报错原文最准：Signature verification failed 或 Invalid signature 是签名失败；The checksum verification failed 或 sha256 does not match 才是哈希不匹配。前者发生在拉取 packages.json 元数据时，后者发生在解压 ZIP 包前——阶段不同、修复动作完全不同。
签名失败的三个真实原因和验证方式
Composer 2.2+ 默认启用 GPG 签名校验，失败即中断，不警告也不降级。常见诱因互不干扰：
- 系统时间偏差 >5 分钟：运行
date对比北京时间，误差超限直接导致 JWT 时间戳校验拒绝 - PHP 加载的 CA 证书过期：执行
php -r "print_r(openssl_get_cert_locations());"，检查default_cert_file指向的文件是否含已吊销证书（如 DST Root CA X3），且最新证书签发时间 ≥2022 年 - 镜像源停服或未同步新签名：运行
composer config -g repo.packagist，输出若为{"type": "composer", "url": "https://packagist.phpcomposer.com"}这类旧地址，该源已于 2025 年底终止服务
交叉验证命令：
直连官方源：curl -I https://packagist.org/packages.json 2>/dev/null | head -1，返回 HTTP/2 200 才说明网络和证书链正常；若报 SSL certificate problem，就是证书路径或内容有问题。
为什么 composer clear-cache 对签名失败完全没用
composer clear-cache 只删 ~/.composer/cache/ 下的下载缓存，不影响时间、证书、镜像配置这三者中的任何一个。签名校验发生在 HTTP 响应解析阶段，和本地缓存 ZIP 包无关。很多用户反复清缓存、换镜像、重装 Composer，却漏掉 date 和 openssl_get_cert_locations() 这两个关键诊断步骤。
真正有效的修复顺序不能乱
签名链是单向依赖：时间不准 → 证书不可信 → 镜像响应被拒。必须按顺序排查：
- 先校准系统时间：Linux/macOS 用
sudo ntpdate -s time.windows.com或timedatectl set-ntp true；Windows 在设置里手动同步 - 再确认证书路径有效：若
default_cert_file不可读或含过期根证书，需更新 ca-certificates 包或手动替换 PEM 文件 - 最后验证镜像：切回官方源测试
composer config -g --unset repos.packagist && composer clear-cache && composer install -vvv，成功后再配阿里云/华为云镜像（注意末尾必须带/）
企业内网常见 TLS 握手卡死，临时诊断可用 composer config -g secure-http false，但验证通过后务必恢复。
