凌晨三点，告警群里一条消息炸开：对账任务又跑偏了。本该在每天 00:30（北京时间）执行的定时对账，实际却在中午 08:30 才触发，整整晚了八个小时，下游报表全部错位。排查一圈下来，根因既不是代码 bug，也不是 cron 写错，而是一个最容易被忽略、却最致命的细节——容器内时区错乱：容器默认走 UTC，而业务期望的是 CST（中国标准时间，UTC+8），定时任务在错误的时钟基准上悄悄运行。本文复盘这次故障的完整排查链路与根治方案。
一、现象：对账任务”跑偏了”
先说清楚表象。我们的对账服务跑在 Docker 容器里，由 Spring 的 @Scheduled 每天 00:30 触发。某天运营反馈：报表数据比预期少了一整天。查日志发现，任务实际的执行时间戳是 16:30 UTC，换算成北京时间是次日 00:30——看起来”对了”，但任务依赖的前置数据在 00:30 还没就绪，于是读到了空数据集。
更迷惑的是：在宿主机上执行 date 明明是 CST，进到容器里 date 却显示 UTC。宿主机和容器”各说各话”，这正是容器内时区错乱最典型的样子。它与单纯的时钟漂移不同（时钟漂移可参考 服务器时钟漂移导致线上故障：NTP/chrony 排查与根治），本质是时区基准不一致而非时间快慢。
二、根因：容器默认 UTC，业务期望 CST
2.1 为什么容器里时间默认是 UTC
绝大多数官方基础镜像（openjdk、ubuntu、alpine 精简版等）为了可移植性，默认把时区设为 UTC，且不带完整的 tzdata 数据。容器共享宿主机内核的时钟（所以”绝对时间”是一样的），但用户态的时区解析依赖 /etc/localtime 和 TZ 环境变量——这些在精简镜像里往往是缺失或指向 UTC 的。
换句话说：硬件时钟是对的，显示给你的”本地时间”是错的。所有按”本地时间”做判断的逻辑都会跟着错。
2.2 哪些环节会被时区影响
凡是”把时间当本地时间用”的地方，都会被波及：cron / @Scheduled 的触发时刻、日志打点的可读时间、数据库 timestamp 字段的存储与读取、文件名里的时间戳、以及对账/计费这类强时间依赖的业务逻辑。
三、三类典型翻车现场
时区问题从来不是孤例。结合踩坑经验，至少有三类”翻车现场”，表象不同、根因一致：
| 场景 | 表象 | 真实根因 |
|---|---|---|
| cron / @Scheduled 定时错位 | 任务在错误时刻触发，或在某些时区切换日直接漏跑 | 调度器按容器 UTC 解析”本地时间”表达式 |
| 日志时间与监控对不上 | 容器日志是 UTC，宿主机/告警是 CST，排查时差 8 小时 | 应用未显式设置时区，跟随容器默认 UTC |
| 数据库时间字段差 8 小时 | datetime 存进去是 UTC，读出来按 CST 解释 | JDBC / ORM 时区与应用、DB 时区三者不一致 |
3.1 crontab / Spring @Scheduled 定时错位
这是最常见也最隐蔽的一种。你以为 0 30 * * * 是”每天北京 0:30″，但 cron 守护进程在容器里读到的本地时区是 UTC，于是真触发在 UTC 0:30，也就是北京 8:30。
3.2 日志时间与监控对不上
容器日志时间戳是 UTC，而你的告警平台、Prometheus（部署见 Docker 编排实战）按 CST 展示，两边永远差 8 小时。一次故障复盘时，光对齐时间线就花掉半小时。
3.3 数据库时间字段与业务时间差 8 小时
Java 应用把 new Date() 写入 MySQL 的 datetime 列，JDBC 连接串没指定 serverTimezone，MySQL 默认按自身时区解释，结果存进去的时间比业务时间早或晚 8 小时。读出来再做时区转换，误差被放大。
四、排查链路：从”现象”到”根因”
遇到可疑的时区问题，按下面这条链路逐层定位，基本不会跑偏。
4.1 先看容器里的时区
进入容器，依次确认三个信号：
# 容器内的当前时间与时区 date # 输出示例：Thu Sep 24 16:30:00 UTC 2026 ← 注意 UTC # 系统级时区配置（部分镜像没有这个命令） timedatectl 2>/dev/null || cat /etc/timezone 2>/dev/null # 或看软链接指向 ls -l /etc/localtime # 期望看到指向 Asia/Shanghai，而非 Etc/UTC
4.2 容器 vs 宿主机比对
在宿主机和容器内分别 date，如果宿主机是 CST、容器是 UTC，说明时区数据/配置没带进容器，而不是时钟本身漂移。这条比对能瞬间排除 NTP 类问题。
4.3 应用层时区配置核查
即使系统时间对了，应用也可能自己”再错一次”：JVM 默认时区来自 user.timezone，Node.js 看 TZ，Python 看 time.tzset()。需要逐一确认应用运行时实际生效的时区，而不是想当然。
五、根治方案：四手准备
临时改文件治标不治本，镜像重建就回到 UTC。要从镜像层面根治，建议四手准备一起做。
5.1 Dockerfile 设置 TZ 环境变量
最干净的方式是在构建期就锁定时区，并装好 tzdata：
FROM openjdk:17-jdk-slim
# 安装时区数据并锁定为上海时区
ENV TZ=Asia/Shanghai
RUN apt-get update \
&& apt-get install -y tzdata \
&& ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai" > /etc/timezone \
&& rm -rf /var/lib/apt/lists/*
# 验证
RUN date # 应输出 CST
5.2 运行时通过环境变量或挂载注入
如果没法改 Dockerfile（比如用第三方镜像），可以在 docker run 或 docker-compose 里注入：
# docker run 方式
docker run -d \
-e TZ=Asia/Shanghai \
-v /etc/localtime:/etc/localtime:ro \
-v /etc/timezone:/etc/timezone:ro \
my-app:latest
# docker-compose.yml 方式
services:
app:
image: my-app:latest
environment:
- TZ=Asia/Shanghai
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
5.3 JVM / 应用层显式指定时区
时区这种事，显式优于隐式。给 JVM 和框架都钉死：
# 启动参数
java -Duser.timezone=Asia/Shanghai -jar app.jar
# Spring Boot 的 Jackson 序列化时区（application.yml）
spring:
jackson:
time-zone: Asia/Shanghai
# JDBC 连接串也要对齐，避免数据库再解释一次
datasource:
url: jdbc:mysql://db:3306/app?serverTimezone=Asia/Shanghai&useUnicode=true
5.4 Kubernetes 环境怎么处理
K8s 里更推荐用环境变量而非挂载宿主机文件（Pod 可能调度到任意节点）：
env:
- name: TZ
value: "Asia/Shanghai"
# 或在基础镜像里装好 tzdata 并设置 TZ，配合 CI（见
# https://fsdata.site/?p=265 GitHub Actions 实战）构建时固化
六、避坑清单与验证
根治后，用下面这张清单做发布前验证，避免”镜像重建又回到 UTC”：
- 镜像构建产物里
date输出应为 CST，而不是 UTC； - CI 流水线（如 GitHub Actions 实战）末尾加一步时区自检，非 CST 则构建失败；
- 定时任务触发前后，对比应用日志与
date输出是否一致； - 数据库写入一条测试记录，确认存储与读出的时间一致且符合业务预期；
- 跨时区服务（多区域部署）一律改用 UTC 存储、展示层再转换，别在存储层混用本地时区。
七、小结
容器内时区错乱是那种”平时毫无存在感、一出事就是数据错位级别”的隐患。它的根因几乎总是：镜像默认 UTC + 应用未显式指定时区。定时任务跑错时间只是表象之一，日志对不齐、数据库差 8 小时都是同源问题。根治口诀就一句：镜像锁 TZ、运行注 TZ、应用钉 TZ、CI 验 TZ。把时区当成和依赖版本一样的一等公民来管理，这类坑下一次就不会再踩。
