日志时间总差8小时？先查系统、容器、应用这三处时区

上线后最容易让人误判的“故障”之一，是日志时间对不上：用户明明在北京时间上午10点操作，日志里却显示凌晨2点。先别急着怀疑业务逻辑，多数情况下只是时区没有统一。下面按系统、容器、应用三处排查。

第一处：主机系统时区

先看主机现在的时间和时区是否一致。执行 date，如果输出是 UTC 而不是 CST，说明主机用的是协调世界时。云服务器镜像默认时区不一定是东八区，特别是在多地部署时更容易出现一台对、一台错的情况。

确认后把时区改成 Asia/Shanghai，再重启依赖时间的服务让它重新读取时区。只改环境变量、不重启服务，是常见的“改了没生效”。

第二处：容器时区

容器默认继承镜像时区，不一定继承主机时区。宿主机时间对了，容器里的时间仍可能是 UTC，这是第二类常见原因。

排查方法是进入容器执行 date，对比宿主机输出。确认不一致后，在启动时挂载主机的 /etc/localtime，或者在镜像里设置 TZ 环境变量。两种方式选一种并固定下来，不要一台容器用一种方式，否则以后排查更乱。

第三处：应用与数据库时区

系统和容器都对了，日志还是差8小时，就要看应用层。常见情况有三种：应用框架默认用 UTC 写日志；数据库连接串没有指定 serverTimezone；前端把 UTC 时间直接显示出来，没有按本地时区转换。

建议统一约定：存储和传输一律用 UTC，只在展示层转换为本地时间。这样跨时区部署、跨国用户访问时，原始数据不会被反复换算弄乱。写日志时同时记录时区信息，排查时一眼就能看出是哪一层出了问题。

一次到位的检查清单

1. 主机 date 输出是否为 Asia/Shanghai。
2. 容器 date 是否与主机一致。
3. 应用日志框架、数据库连接、前端展示是否各自明确时区。
4. 修改后是否重启了相关服务。

按这个顺序查，多数“时间差8小时”几分钟就能定位，不用把整个链路翻一遍。