Docker容器时区与locale应通过构建阶段预设（如安装tzdata、设置软链、生成locale并配置ENV）和运行阶段注入环境变量（-e TZ -e LANG）双重保障，辅以date/locale等命令验证，避免挂载宿主机时区等不可靠方式。
在 Docker 容器中，镜像默认通常使用 UTC 时区，且 locale（本地化）常设为 C 或 C.UTF-8，这会导致中文显示乱码、时间显示不匹配、日志时间错位、date 命令输出非本地时间等问题。解决方法不是“运行时硬改”，而是从镜像构建和容器启动两个层面合理配置。
构建阶段：在 Dockerfile 中预设时区与 locale
推荐在基础镜像拉取后、应用安装前就完成时区和本地化设置，确保所有后续命令（如编译、脚本执行）都基于正确环境运行。
- 对于 Debian/Ubuntu 镜像：安装
tzdata并用ln -sf软链设置时区，同时通过locale-gen启用所需 locale - 对于 Alpine 镜像：安装
tzdata包，并复制对应时区文件到/etc/localtime；locale 支持有限，建议使用en_US.UTF-8或直接依赖系统默认的C.UTF-8 - 关键操作需配合
ENV设置环境变量：TZ（如TZ=Asia/Shanghai）和LANG（如LANG=zh_CN.UTF-8），部分程序（如 Java、Python）会读取这些变量生效
示例（Ubuntu）：
RUN apt-get update && \
apt-get install -y tzdata locales && \
rm -rf /var/lib/apt/lists/* && \
locale-gen zh_CN.UTF-8 && \
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
echo "Asia/Shanghai" > /etc/timezone
ENV TZ=Asia/Shanghai LANG=zh_CN.UTF-8 LANGUAGE=zh_CN:zh
运行阶段：容器启动时覆盖或补充配置
若无法修改镜像（如使用第三方官方镜像），可通过运行参数动态注入时区和 locale，适用于调试、临时验证或 CI/CD 场景。
- 挂载宿主机时区文件：
-v /etc/localtime:/etc/localtime:ro（注意权限与一致性，仅推荐宿主机与容器同为 Linux 且时区一致时使用） - 更可靠的方式是传入环境变量：
-e TZ=Asia/Shanghai -e LANG=zh_CN.UTF-8，多数现代运行时（Node.js、Python、Java）会识别并自动适配 - 对 Alpine 等精简镜像，若无
locale-gen，可跳过生成步骤，只设LANG=C.UTF-8保证 UTF-8 编码支持，避免中文乱码
验证是否生效的实用命令
进入容器后，用以下命令快速确认配置结果：
-
date—— 检查当前时间是否为预期时区时间 -
timedatectl status 2>/dev/null || echo "not available"—— 在 systemd 容器中查看详细时区状态（多数 Docker 镜像不含 systemd，可忽略） -
locale—— 查看当前 locale 设置，确认LANG、LC_TIME等字段正确 -
ls -l /etc/localtime—— 确认软链接指向正确的 zoneinfo 文件 -
echo $TZ—— 确保环境变量已加载
常见陷阱与规避建议
很多问题源于“半途配置”或“多层覆盖”，需特别注意：
- Java 应用可能忽略
TZ环境变量，需额外加 JVM 参数：-Duser.timezone=Asia/Shanghai - 某些 Alpine 镜像（如
openjdk:alpine）默认无中文 locale，locale -a | grep zh为空，此时设LANG=zh_CN.UTF-8无效，应改用LANG=C.UTF-8并确保应用自身支持 UTF-8 字符渲染 - 使用
docker commit保存临时修改的容器为新镜像，不会持久化ENV变量（除非原镜像已定义），也不推荐该方式——应坚持用 Dockerfile 构建 - Windows/macOS 上的 Docker Desktop 默认使用 UTC，其“宿主机时区挂载”行为与 Linux 不同，跨平台部署时优先以环境变量为准
不复杂但容易忽略。核心就两条：构建时写进镜像，运行时用环境变量兜底，再加一条验证习惯，基本就不会踩坑。
