composer 报 signature verification failed 或 filemtime() 错误，90% 是系统时间偏差超 5–15 分钟所致；应先用 date 和 curl -i https://packagist.org 提取 date 响应头比对 utc 时间，偏差超 60 秒即需修正，wsl2 可临时执行 sudo hwclock --hctosys，linux 服务器优先启用 systemd-timesyncd 并禁用 chronyd，ci 中加 sleep 2 && timedatectl timesync-status 等待校准，docker 容器须挂载 /etc/localtime。
Composer 报 signature verification failed 或 filemtime(): stat failed，90% 是系统时间偏差超 5–15 分钟导致的，不是镜像、证书或网络问题。
怎么快速确认是不是时间问题
别猜，直接比对：
- 运行
date看本地时间，如果明显偏离（比如显示 2022 年或 2026 年某月某日），基本坐实 - 执行
curl -I https://packagist.org 2>/dev/null | grep Date，提取响应头里的Date字段 - 用
date -u输出 UTC 时间，和上一步的Date值对比——差超过 60 秒就要修 - 在 WSL2 里报错但 Windows 时间正常？运行
sudo hwclock --hctosys临时同步一次，若修复成功，就是 WSL2 虚拟时钟漂移
Linux 服务器该用 systemd-timesyncd 还是 chrony
优先启用 systemd-timesyncd，它轻量、无额外依赖、与 systemd 深度集成：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查状态：
timedatectl status，重点看System clock synchronized: no和NTP service: inactive - 启用：
sudo timedatectl set-ntp true - 如果
ps aux | grep chronyd显示它正在运行，先停用：sudo systemctl stop chronyd && sudo systemctl disable chronyd——两个 NTP 服务争抢会导致时间反复跳变 - 指定可信内网 NTP 源：编辑
/etc/systemd/timesyncd.conf，改Servers=行，例如Servers=192.168.1.100 pool.ntp.org，再重启服务
Docker 容器和 CI 环境的时间陷阱
容器默认共享宿主机 clock，但很多场景下这个“共享”是失效的：
- CI 流水线（如 GitHub Actions）启动极快，NTP 可能还没完成首次同步就执行了
composer install，导致偶发失败；建议在 CI 脚本开头加sleep 2 && timedatectl timesync-status等待校准就绪 - Docker Compose 部署时，必须挂载宿主机时区文件：
volumes: - /etc/localtime:/etc/localtime:ro，否则即使宿主机时间准，容器内date仍可能显示错误 - WSL2 不是简单配 NTP 就行——它休眠后虚拟时钟不自动追时；永久解法是在
/etc/wsl.conf加[boot] systemd=true，并确保 Windows 的「Windows Time」服务已启用 - 别在容器里跑
date -s，它不持久、破坏systemd-timesyncd自动逻辑，且重启即丢
时间不准是底层硬伤，它会让镜像配置、HTTPS 设置、JWT 验证全部失效。修时间不是“试试看”，而是所有 Composer 故障排查的第一步——哪怕报错里一个字没提“time”。
