在使用 Docker 或其他容器技术打包应用时，很多人会忽略一个看似不起眼却影响很大的细节——时区。你有没有遇到过这样的情况：程序日志里的记录时间比本地慢了8小时，排查半天才发现是容器内部时间用的是 UTC？这问题根源就在镜像构建时没做好时区配置。
为什么时区会出问题？
大多数基础镜像（比如 Alpine、Ubuntu 官方镜像）默认使用 UTC 时间。UTC 没毛病，全球统一标准嘛，但对国内用户来说，日志、定时任务、数据库写入时间全显示成 UTC，查问题就得自己脑内换算，太折腾。尤其在处理跨时区业务或调试线上异常时，差一秒都可能影响判断。
构建镜像时怎么设置时区？
以常见的 Ubuntu 镜像为例，在 Dockerfile 里加几行就能搞定：
FROM ubuntu:20.04
# 设置时区为 Asia/Shanghai
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
# 安装必要软件（可选）
RUN apt-get update && apt-get install -y tzdata
这里的关键是通过环境变量 TZ 指定时区，并用 ln -snf 软链接替换系统 localtime 文件。同时把时区名称写入 /etc/timezone，保证系统工具能正确识别。
Alpine 镜像怎么办？
Alpine 更轻量，但默认不带完整的时区数据。你需要先安装 tzdata 包，再复制对应文件：
FROM alpine:latest
# 安装时区数据并设置上海时区
RUN apk add --no-cache tzdata && \
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
echo "Asia/Shanghai" > /etc/timezone && \
apk del tzdata
注意最后删掉 tzdata 包是为了减小镜像体积，因为只需要里面的时区文件，包本身用完就可以卸载。
Java 应用要额外注意
如果你跑的是 Java 服务，JVM 有时会忽略系统时区，得手动传参：
java -Duser.timezone=Asia/Shanghai -jar app.jar不然就算系统时区对了，Spring Boot 日志时间还是可能不对。这个坑不少人踩过，特别是做定时任务（@Scheduled）的时候，时间对不上就尴尬了。
实际场景举例
老张公司上线了个订单统计服务，每天凌晨1点跑前一天的数据。结果连续几天漏统计，一查日志发现容器时间是 UTC，所谓的“凌晨1点”其实是北京时间上午9点。改完时区配置后，定时任务终于准时执行，老板也没再追问为啥报表总延迟。
这种问题不大，但一旦发生就容易让人怀疑人生。与其等出了事再改，不如在构建镜像阶段就把时区设好，省得后续扯皮。