折腾半小时：Docker 容器时间不对竟是因为没挂时区？

最近在部署一个定时任务的时候，遇到了一个让我差点怀疑人生的问题：任务每次执行的时间都比预期晚了整整 8 个小时。一开始我理所当然地以为是自己的 cron 表达式写错了，反反复复检查、修改、重启，折腾了好半天，问题依旧。

实在没招了，我只好乖乖地进容器里看了一眼，输入 date 命令后瞬间破防——容器里显示的时间是 UTC（世界标准时间），而我的宿主机明明是 CST（中国标准时间）。好家伙，原来是时区没对上，白瞎了我半小时去改那些本来就没错的代码。

在容器内输入 date 命令发现时间显示为 UTC，与宿主机的 CST 时间不一致。

这个问题其实非常经典，尤其是当你使用的是官方基础镜像（如 Alpine 或某些精简版 Debian）时，它们默认为了保持“纯净”和“通用”，往往不会预设时区，导致时间和日志记录全都乱套。

为了让大家不再踩我踩过的坑，我整理了一下解决这个问题的三种主流方案，顺便分析一下各自的优劣，看看哪种最适合你。

方案一：挂载宿主机时区文件（最推荐）

这是我个人最推荐的做法，也是最干净、最直接的方式。它的原理很简单，直接把宿主机的时区配置文件“映射”进容器里，这样容器的时间就会永远和宿主机保持一致，无论宿主机怎么改时区，容器都会自动跟着变。

在 docker-compose.yml 中配置如下：

在 docker-compose.yml 中挂载时区文件的代码示例。

volumes:
  - /etc/localtime:/etc/localtime:ro
  - /etc/timezone:/etc/timezone:ro

优点：

1. 一劳永逸：不用在构建镜像时做手脚，也不用担心镜像里的 tzdata 包版本问题。
2. 灵活性高：如果你以后宿主机改了时区（比如搬去国外服务器），容器不用重新构建就能自动同步。
3. 只读挂载：加上 :ro 参数更安全，防止容器内部进程意外修改宿主机的时区文件。

方案二：设置环境变量 TZ

通过环境变量 TZ 设置时区的配置方法。

这种方法比较优雅，很多现代化的镜像都已经支持自动识别 TZ 环境变量。你只需要在启动容器时指定一下时区即可。

environment:
  - TZ=Asia/Shanghai

在 Dockerfile 中建立软链接以固定时区的方法。

缺点也很明显： 这个方案生效有一个大前提——你的镜像里必须安装了 tzdata（时区数据包）。如果是像 Alpine 这种极致精简的镜像，默认是不带这个包的。如果没装，你设置了环境变量也等于没设。这就需要你在 Dockerfile 里额外加一句安装命令，稍微增加点镜像体积。

方案三：在 Dockerfile 里建立软链接

如果你是追求容器“自给自足”的极致派，不希望依赖宿主机的文件结构，那么可以在构建镜像时就直接把时区写死。

在 Dockerfile 中添加：

RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

适用场景： 这种方式适合那些固定部署在特定区域的应用。但它的缺点是缺乏灵活性，一旦镜像构建完成，时区就死死定在里面了。如果以后要换地域部署，就得重新构建镜像。

总结与建议

综合对比下来，对于绝大多数运维和开发场景，方案一（挂载时区文件） 是最省心且不易出错的。它不需要修改镜像，也不依赖容器内的额外包，拿来即用。

当然，如果你使用的是云原生的编排工具（比如 Kubernetes），通常也有更高级的通过 Pod Preset 或挂载 ConfigMap 来统一管理时区的方法，核心原理其实和挂载文件是异曲同工。

不知道大家在日常开发中是用哪种方案？有没有遇到过因为时间不对导致的奇葩 BUG？欢迎在评论区交流一下避坑经验！