system.currenttimemillis()返回的是自1970-01-01 00:00:00 utc起的毫秒数，是时区无关的绝对utc时间戳；后续格式化、显示或计算零点时间时才需显式指定时区，误用本地时区是常见错误根源。
System.currentTimeMillis() 返回的是自 1970-01-01 00:00:00 UTC 起经过的毫秒数，它本身是时区无关的 —— 它就是一个绝对时间戳（UTC 时间）。所以它不“跨时区”，也不需要“处理”跨时区问题。真正容易出错的，是后续用这个时间戳做格式化、解析、计算或显示时，**误用了本地时区或错误设定了时区**。
别把时间戳当“本地时间”用
很多人看到 System.currentTimeMillis() 输出一个数字（比如 1717023456789），下意识觉得“这是我现在的时间”，然后直接传给 SimpleDateFormat 或 Calendar 却没设时区，结果在不同时区机器上显示不同时间，误以为“跨时区出问题了”。其实问题不在时间戳，而在显示逻辑。
- 时间戳本身是标准的 UTC 基准，全球一致
- 只有把它转成“年月日时分秒”这种人类可读形式时，才涉及时区解释
- 例如：同一时间戳在东八区显示为
2024-05-30 14:30:45，在西五区显示为2024-05-30 01:30:45—— 这不是时间错了，是展示视角不同
正确使用时间戳做跨时区场景
如果你要支持多时区用户（比如记录日志、显示本地时间、计算时差），关键不是改时间戳，而是统一用 Instant + ZonedDateTime 显式指定时区：
- 获取当前时刻：用
Instant.now()（本质就是System.currentTimeMillis()的现代封装） - 转成本地时间显示：比如用户在东京，就用
instant.atZone(ZoneId.of("Asia/Tokyo")) - 转成其他时区对比：比如查“北京时间 10 点，纽约几点”，用
zdt.withZoneSameInstant(ZoneId.of("America/New_York")) - 存数据库或网络传输时，始终用
Instant或 UTC 时间戳，避免歧义
警惕 SimpleDateFormat 和 Calendar 的陷阱
老式 API 默认使用 JVM 默认时区（由 user.timezone 或系统决定），极易导致跨服务器/跨地区行为不一致：
-
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date())→ 依赖默认时区 - 解决办法：显式设置时区，如
sdf.setTimeZone(TimeZone.getTimeZone("UTC")) - 更推荐：直接用
DateTimeFormatter配合Instant或ZonedDateTime，比如：Instant.now().atZone(ZoneId.of("Europe/London")).format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))
服务端统一用 UTC，前端按需转换
典型稳健做法：
- 后端所有时间存储、计算、接口返回，都用 UTC 时间戳或 ISO 格式字符串（如
"2024-05-30T06:30:45Z"） - 前端 JavaScript 用
new Date(timestamp)自动按浏览器本地时区渲染 - 如需固定时区显示（比如客服系统统一显示北京时间），前端明确调用
.toLocaleString('zh-CN', {timeZone: 'Asia/Shanghai'}) - 避免后端硬编码
"GMT+8"或"CST"这类模糊缩写（CST 可能指中国标准时间，也可能指美国中部时间）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
