服务器时间快了八小时

日志时间比实际快了整整八小时，基本可以断定时区没设对：系统在用 UTC 计时，而业务按北京时间理解。 ## 先看当前状态 两条命令摸清现状： timedatectl date -R 重点看 Time zone 一行和实际输出的时间。时区显示 UTC 而 date 比北京时间快八小时，属于最典型的 UTC 与东八区混淆——UTC 是协调世界时，北京时间（Asia/Shanghai）比它快八小时，同一个时刻两种写法差出来的就是这八小时。 date 输出末尾带时区后缀（UTC 或 CST），不带后缀的日志时间单看数字没法比较，很多"时间不准"的误报源于此。 ## 一步修正时区 timedatectl set-timezone Asia/Shanghai 执行完再用 timedatectl 复查，时区变为 Asia/Shanghai、显示时间与手机一致即成功。老系统没有 timedatectl 的，用软链方式也可以：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime。改完与手机对一次秒，或比对一个公开时间接口的返回，确认显示层面已经一致。 ## 别忽略连带影响 时区改动即刻生效，但已存的日志不会追溯，旧记录的时间戳仍是 UTC 口径，翻历史日志时注意换算。计划任务要按新时区重新对表，原本"凌晨三点"的任务实际落点可能变了。数据库里 NOW() 这类函数的返回值也随全局时区变化，依赖时间的业务逻辑要过一遍。PHP 还有自己的时区配置（php.ini 的 date.timezone），一并核对。单独挂了 TZ 环境变量的容器，时区独立于宿主机，宿主机改完容器未必跟着变，逐个确认。 接口签名的时间戳、证书有效期判断、日志审计排序，全都依赖时间口径统一，这类修正宜早不宜迟。 ## 让时间不再漂 时区对了还要保证时钟本身准确，开启网络对时： timedatectl set-ntp true chronyd 或 systemd-timesyncd 服务处于运行状态即可，偏差会被持续校准。云服务器默认多半开着对时，人为停过 chronyd 的机器最容易漂，巡检时顺手 systemctl status chronyd 看一眼。改完顺手重启一次 cron 服务更稳妥。新机器初始化清单里加一条 timedatectl，八小时偏差基本可以绝迹。