引言
在维护一个基于Spring Boot的Java应用时，我遇到了一个奇怪的问题：服务器执行date命令显示的时间是正确的（CST，东八区），但应用打印的日志时间却整整少了8小时（显示为UTC时间）。这篇文章记录了从现象到根源的完整排查过程，希望能帮助遇到类似问题的开发者少走弯路。
问题现象
服务器环境：Ubuntu，JDK 17.0.8，Spring Boot应用
异常表现：应用日志（通过logback输出）中的时间戳比实际系统时间少8小时。例如，系统时间为
2026-04-01 10:30:45，日志却显示2026-04-01 02:30:45。正常现象：系统
date命令显示时间正确；硬件时钟（hwclock）也正确。
初步排查思路
由于日志时间与系统时间恰好相差8小时（即UTC与CST的差值），直觉告诉我这是时区配置不一致导致的。通常，Java应用的日志时间会使用JVM的默认时区进行格式化，如果JVM时区为UTC，而系统时区为CST，就会出现这种偏差。
1. 检查系统时区
bash
timedatectl输出显示时区为 Asia/Shanghai (CST, +0800)，看起来正确。
2. 检查JVM默认时区
在Spring Boot启动类中添加代码打印JVM时区：
java
@PostConstruct
public void init() {
System.out.println("JVM default timezone: " + java.util.TimeZone.getDefault().getID());
}重启后控制台输出：JVM default timezone: UTC。确认JVM确实使用了UTC时区。
3. 检查启动命令
应用启动命令如下：
bash
/www/server/java/jdk-17.0.8/bin/java -jar -Xmx1024M -Xms256M /www/wwwroot/evcharge/jar/rg-mini-program.jar命令中没有显式指定 -Duser.timezone，理论上JVM应该自动读取系统时区。
4. 尝试强制指定时区
在启动命令中加入 -Duser.timezone=Asia/Shanghai，重启后日志时间恢复正常。这证实了问题就是JVM时区获取错误。
但为什么明明系统时区已经是CST，JVM却读成了UTC呢？
深入挖掘：时区文件的不一致
经过搜索和查阅资料，我发现Linux系统中时区设置涉及两个关键文件：
/etc/localtime：二进制时区数据文件，date等命令通过它获取时区信息。/etc/timezone：文本文件，存储时区名称（如Asia/Shanghai），部分程序（包括Java）会优先读取该文件来确定时区。
我执行了以下命令：
bash
ls -l /etc/localtime输出为：
text
/etc/localtime -> /usr/share/zoneinfo/Asia/Shanghai链接正确指向了东八区时区文件，这解释了为什么date命令显示正确。
再查看 /etc/timezone：
bash
cat /etc/timezone输出为：
text
Etc/UTC原因找到了！ /etc/timezone 文件残留着旧的UTC时区设置，导致Java在启动时读取到UTC，而系统date则通过/etc/localtime获得了CST。
为什么会出现这种不一致？
推测服务器最初安装时系统时区为UTC，后来管理员通过 timedatectl set-timezone Asia/Shanghai 调整了时区。正常情况下该命令会同时更新 /etc/localtime 和 /etc/timezone，但可能由于某些异常（如手动修改过文件、系统版本差异等），导致 /etc/timezone 未被更新，从而出现不一致。
解决方案
修正 /etc/timezone 文件
bash
echo "Asia/Shanghai" | sudo tee /etc/timezone或者直接编辑文件：
bash
sudo nano /etc/timezone将内容改为 Asia/Shanghai，保存退出。
重启应用
bash
# 停止当前应用
pkill -f rg-mini-program.jar
# 重新启动（无需额外参数）
/www/server/java/jdk-17.0.8/bin/java -jar -Xmx1024M -Xms256M /www/wwwroot/evcharge/jar/rg-mini-program.jar验证结果
启动后再次观察日志，时间戳已恢复为CST时间。打印JVM时区的代码输出：
text
JVM default timezone: Asia/Shanghai问题解决！
补充说明：其他可能导致JVM时区错误的因素
在排查过程中，我还注意到其他可能引起类似问题的原因，一并记录如下：
环境变量
TZ：如果启动脚本或容器中设置了TZ=UTC，JVM会优先使用环境变量定义的时区。Docker容器时区未挂载：容器内默认UTC，需要通过
-e TZ=Asia/Shanghai或挂载/etc/localtime来修正。JVM启动后修改系统时区：JVM在启动时读取时区后不会动态更新，重启应用才能生效。
但本次问题的根源是 /etc/timezone 文件内容错误，属于比较隐蔽的情况，值得记录。