云服务器日志总差 8 小时？顺着时区链路一路排查到容器与数据库

把服务从本地搬到华为云 ECS 之后，最常见的一类"玄学问题"是时间。日志里记录的是 UTC 时间，业务库里存的是本地时间，前端展示又差一截；排查故障时对着三个不同时间轴看，几乎没法定位。

这类问题的根因高度集中：整条链路上只要有一处是 UTC，就会出现 8 小时偏差。下面按"宿主机 → 容器 → 运行时 → 应用日志 → 数据库 → 前端"的顺序把每一环说清楚，最后给一套一次性治理的检查清单。

一、先确认偏差方向，不要瞎改

动手前先明确三件事：

1. 宿主机当前时间：date、timedatectl，看 Time zone 是 UTC 还是 Asia/Shanghai；

2. 应用实际写入的时间戳：同一条请求，在应用里打一行 System.currentTimeMillis() 或 time.time()，和服务器 date 对比；

3. 偏差是固定 8 小时（时区问题），还是随运行时间逐渐变大（NTP 没同步，硬件时钟漂移）。

固定 8 小时 = 时区；越跑越偏 = 时钟同步。两种处理方式完全不同，别一上来就改 TZ 环境变量。

二、宿主机时区

华为云公共镜像默认多为 UTC（部分镜像为 Asia/Shanghai，与创建时选择的镜像版本有关）。确认后统一设为东八区：

sudo timedatectl set-timezone Asia/Shanghai

timedatectl

timedatectl 的输出里要同时确认两行：Time zone: Asia/Shanghai (CST, +0800)、System clock synchronized: yes。第二行为 no 说明 chronyd/ntpd 没在工作，需要 systemctl status chronyd 检查，必要时 systemctl enable --now chronyd。

注意 /etc/localtime 是符号链接，直接 cp 覆盖会让 timedatectl 显示与实际不一致；用 timedatectl 或 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 才是正确姿势。

三、容器是最容易被忽略的一层

很多人改完宿主机就以为结束了，但容器里的时区默认继承自镜像（基础镜像 alpine、debian-slim、ubuntu 多为 UTC），跟宿主机无关。这就是"宿主机 date 对、容器里 date 差 8 小时"的原因。

三种修法，按推荐度排序：

1. 挂载宿主机时区文件（最简单，无副作用）：

   docker run -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro ...

2. 设置环境变量 TZ=Asia/Shanghai。注意它只对 glibc 和应用层生效，busybox 里 date 命令仍可能显示 UTC，要配合安装 tzdata；

3. 构建镜像时 apt install -y tzdata && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime，一劳永逸但需要重建镜像。

Kubernetes 场景同理：Pod 里没有 tzdata 的话，TZ 变量设置了也不生效，因为时区数据库根本不存在。标准做法是在 Pod 模板里挂载 /etc/localtime 与 /usr/share/zoneinfo。

四、语言运行时的时区处理

Java：JVM 启动时读取系统时区并缓存，改了系统时区不重启进程等于没改。JDK 9 之前还有 user.timezone 缓存问题，建议显式指定 -Duser.timezone=Asia/Shanghai，避免依赖环境。日志框架（logback/log4j2）的时间格式里如果写了 %d{yyyy-MM-dd HH:mm:ss} 而未指定时区，用的是 JVM 默认时区。

Python：datetime.now() 返回本地时间，datetime.utcnow() 返回 UTC。现在更推荐 datetime.now(timezone.utc) 拿到带 tzinfo 的对象，避免 naive datetime 引发比较错误。Django 项目里 USE_TZ=True 时数据库存的是 UTC，模板渲染时按 TIME_ZONE 转换，这种情况"库里是 UTC"是正确行为，不要盲目改成 False。

Node.js：new Date() 的 toString 受 TZ 影响，但 toISOString 永远是 UTC。写入数据库时如果 ORM 没做时区转换，很容易存进 UTC。建议全链路统一存 UTC、展示层转换。

五、日志与数据库

应用日志：容器里如果用 docker logs 采集，日志时间来自文件内容而非采集时间，所以容器时区没设好，日志就会整体偏 8 小时。用 Filebeat/Fluent Bit 采集时注意不要再用采集时间覆盖日志里的原始时间戳。

MySQL：服务器 time_zone 参数默认 SYSTEM，跟随操作系统。show variables like '%time_zone%' 查看。TIMESTAMP 类型会做时区转换（存 UTC、按 time_zone 取出），DATETIME 不做转换。很多"存进去和取出来差 8 小时"的问题，本质是 TIMESTAMP + 时区参数不一致，或者 JDBC 连接串缺 serverTimezone 参数。建议连接串显式写 serverTimezone=Asia/Shanghai 或统一用 UTC。

PostgreSQL：timestamp with time zone 存 UTC，timestamp without time zone 存字面值。跨时区服务混用两种类型几乎必踩坑。

Redis：没有时区概念，但 ZSET 存的时间分数字段如果来自不同时区的服务，排序结果就会错乱。

六、前端

浏览器按运行设备的本地时区渲染，接口返回 UTC 时间（带 Z 后缀）时 new Date() 会自动转成用户本地时间，这是期望行为。但如果接口返回的是不带时区的 "2026-10-22 00:55:00"，浏览器会按本地时区解析，服务端和客户端时区不同时就会显示错乱。规范做法：接口统一返回 ISO8601 带时区偏移（如 2026-10-22T00:55:00+08:00）或 UTC 带 Z。

七、一次性治理的检查清单

1. 宿主机 timedatectl 两行都正确，chronyd 开机自启；

2. 所有容器挂载 /etc/localtime（K8s 用 hostPath 挂载进 Pod）；

3. JVM 显式 -Duser.timezone，Python 用 timezone.utc，Node 用 toISOString；

4. MySQL 连接串显式 serverTimezone，业务表统一时间类型（TIMESTAMP 或 BIGINT 毫秒二选一）；

5. 接口统一 ISO8601 带偏移，前端不做二次时区猜测；

6. 加一条监控：服务每分钟上报本机时间与应用时间差，超过 60 秒告警。

结语

时间偏差问题看似零散，实际就是一条"谁有权决定时区"的链条：宿主机定基调，容器继承镜像、需要显式干预，运行时缓存时区、需要重启，数据库和接口负责存储与传输格式。把这条链路一次性捋顺，比每次出问题逐个容器改要省事得多。同时也建议在运维规范里写死：服务器统一 Asia/Shanghai，对外接口统一带时区偏移，日志与数据库时区口径一致。

参考命令

timedatectl set-timezone Asia/Shanghai

timedatectl; date; hwclock --show

docker run -v /etc/localtime:/etc/localtime:ro -e TZ=Asia/Shanghai your-image

kubectl get pod xx -o yaml | grep -A3 volumeMounts

以上经验来自在华为云 ECS（Ubuntu/Debian 系镜像）上部署后端服务时的实际排查过程，不同镜像版本默认时区略有差异，以 timedatectl 输出为准。