signature verification failed是因系统时间与Packagist响应头Date偏差超15分钟触发的签名时间戳校验失败，根本未进入网络超时逻辑；需用date -u和curl -I比对UTC时间，超60秒即须修复，并删除vendor和composer.lock后重装。
不是超时，是签名验证失败——系统时间偏差超过15分钟会直接触发 signature verification failed，根本不会走到“超时”那步。
为什么 signature verification failed 不是网络超时
Packagist 的包签名含时间戳，Composer 在下载后第一件事就是校验该时间戳是否在服务端当前时间 ±15 分钟内。它不依赖 http.timeout 或 process-timeout，而是直接比对本地 date 和响应头 Date 字段。一旦偏差超限，立刻中止并报错，连 dist.sha256 都不会读。
- 错误现象：卡在
Installing dependencies后突然报signature verification failed或filemtime(): stat failed - 常见于 WSL2、Docker 容器、CI 流水线（如 GitHub Actions 启动瞬间）、虚拟机休眠唤醒后
- 和镜像源、代理、
composer.lock内容、PHP 版本都无关
怎么确认是时间偏差导致的
别改配置，先验证：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
date -u，记下输出（UTC 时间） - 运行
curl -I https://packagist.org 2>/dev/null | grep -i date，提取Date:响应头（也是 UTC） - 两者差值超过 60 秒，就必须修正；超过 900 秒（15 分钟），就必然失败
例如：date -u 输出 Mon Oct 12 15:42:10 UTC 2026，而 Date 头是 Mon, 12 Oct 2026 15:43:05 GMT —— 差 55 秒，安全；若差 16 分钟，就已越界。
修复时间同步的实操步骤
不同环境修复方式差异大，不能一招鲜：
- Linux 服务器：运行
sudo timedatectl set-ntp true，再检查timedatectl status中System clock synchronized: yes是否出现 - WSL2：执行
sudo hwclock --hctosys临时同步；永久解法是在/etc/wsl.conf加[boot] systemd=true，并确保 Windows 主机「Windows Time」服务开启 - Docker 容器：必须挂载宿主机时区文件，
docker run -v /etc/localtime:/etc/localtime:ro ...；CI 中（如 GitHub Actions）建议加sleep 2 && timedatectl timesync-status等待 NTP 就绪 - 修复后必须删掉
vendor/和composer.lock，再重新composer install—— 旧锁文件里记录的哈希和时间戳已失效
别在错误方向上浪费时间
调 process-timeout、换镜像、清缓存、重装 Composer，对 signature verification failed 全无效。这个错误只认时间，且校验发生在网络传输完成之后、解压之前，是纯本地逻辑。最容易被忽略的是 WSL2 和 CI 容器的时间漂移——它们看起来“时间没错”，但和 Packagist 服务端 UTC 对不上。
