System.currentTimeMillis() 返回的是与时区无关的 UTC 时间戳，问题出在后续解析和展示环节；正确做法是显式指定时区（如 Instant + ZoneId），避免依赖 JVM 默认时区，并在日志、数据库、API 中明确时区上下文。
System.currentTimeMillis() 本身与时区完全无关，它返回的是自 1970-01-01 00:00:00 UTC 起经过的毫秒数，是一个绝对时间点。真正出问题的环节，是后续对这个 long 值的解析和展示——比如用 Date.toString()、SimpleDateFormat 或错误地传给 LocalDateTime.ofInstant()，这些操作会悄悄套用 JVM 默认时区，导致同一时间戳在不同环境显示成不同时间。
理解时间戳的本质
时间戳不是“北京时间”或“纽约时间”，它只是数字。就像一把尺子量出的长度，不自带单位标签。你看到“2025-04-05 10:00”这个字符串，其实是把同一个时间戳，在某个时区上下文里“翻译”出来的结果。
- 在北京服务器上调用
System.currentTimeMillis()，得到的值和在伦敦、东京服务器上完全一致（实测可验证） - 但
new Date(timestamp).toString()会按本地 JVM 时区渲染，所以北京显示“CST”，伦敦显示“BST”，内容不同 - 数据库存时间戳时，如果没注明是 UTC，查出来再用本地时区解析，就可能错位8小时
安全转换目标时区时间
要用时间戳表示某个具体时区下的日历时间，必须显式指定时区，不能依赖默认值。
- 推荐用 Java 8+ 的
Instant+ZoneId：Instant instant = Instant.ofEpochMilli(timestamp);ZonedDateTime zdt = instant.atZone(ZoneId.of("Asia/Shanghai")); - 格式化时也绑定时区：
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss").withZone(ZoneId.of("Asia/Shanghai")) - 避免用
SimpleDateFormat，它不是线程安全的，且容易忽略时区设置；若必须用，记得调用setTimeZone()
跨时区业务逻辑判断
做“是否跨天”“是否在今日内”这类判断时，不能直接比对时间戳数值，而要落到具体时区的日历语义上。
- 例如判断订单是否属于“今天（北京时间）”：先将时间戳转为
ZonedDateTimewithZoneId.of("Asia/Shanghai")，再用toLocalDate().equals(LocalDate.now(ZoneId.of("Asia/Shanghai"))) - 对比两个时间点是否在同一“工作日”（如周一到周五），也要统一到同一时区再提取
DayOfWeek - 生成 JWT 过期时间等安全敏感场景，务必明确声明时区，避免因服务器部署位置不同导致校验失败
日志与存储建议
原始时间戳永远保留 UTC 含义，但记录上下文能极大降低排查成本。
- 写日志时，除了打印
timestamp=1749791000000，最好附带可读时间（带时区）：time=2026-06-13T05:03:20+08:00[Asia/Shanghai] - 数据库字段命名可加后缀提示，如
create_time_utc或create_time_ms，避免歧义 - API 返回时间字段，优先用 ISO 8601 字符串（如
"2026-06-13T05:03:20Z"），而非裸 long，前端/客户端无需猜测时区
