System.currentTimeMillis()返回的是自1970年1月1日00:00:00 UTC起的毫秒数，为long类型绝对时间戳，与本地时区无关，但受系统时钟调整影响，不适用于精确计时。
System.currentTimeMillis() 返回的是自协调世界时（UTC）1970年1月1日 00:00:00 起经过的毫秒数，它本质上是基于系统底层的“挂钟时间”（wall-clock time），与本地时区无关，但受系统时钟设置影响。
它不等于本地时区的当前时间
该方法返回的是一个绝对时间戳（UTC毫秒值），不是格式化后的本地时间。例如，北京时间（UTC+8）2024年6月1日 10:00:00 对应的时间戳，和纽约时间（UTC-4）同一天 02:00:00 是同一个数值。显示为“几点几分”需要配合 SimpleDateFormat、DateTimeFormatter 或 Calendar 等做时区转换和格式化。
它依赖操作系统时钟，可能被手动或自动调整
该值由操作系统提供，若用户修改了系统时间，或系统启用了 NTP 时间同步服务（如 Windows 时间服务、Linux 的 systemd-timesyncd/chronyd），时间戳会随之跳变。因此它不适合用于精确测量耗时（比如性能分析），推荐使用 System.nanoTime() 替代。
它不能直接反映夏令时或本地历法变化
时间戳本身无夏令时概念；是否应用夏令时偏移，取决于你后续如何解析它。例如用 SimpleDateFormat 格式化时传入 TimeZone.getTimeZone("America/New_York")，它会自动按该时区当年的夏令时规则计算显示时间；但时间戳数值不变。
常见误用提醒
- 把
currentTimeMillis()当作“本地小时数”直接除以 3600000 使用——结果仍是 UTC 小时，需先转为LocalDateTime或Calendar并设对时区 - 在分布式系统中假设所有机器时间完全一致——实际存在毫秒级偏差，需依赖 NTP 或逻辑时钟（如 Lamport timestamp）协同
- 用它判断“今天凌晨0点”却未指定时区——必须明确是以哪个时区的“今天”为准，再通过
ZonedDateTime.withHour(0).withMinute(0)...计算对应时间戳
