Instant.toEpochMilli()返回自1970-01-01T00:00:00Z起的毫秒数，long类型，精度毫秒，截断纳秒不四舍五入；需确保Instant非null，常见来源有Instant.now()、Instant.parse()及LocalDateTime转UTC再转Instant。
Instant.toEpochMilli() 直接返回自 1970-01-01T00:00:00Z（UTC）起经过的毫秒数，结果是 long 类型，精度为毫秒。
核心用法很简单
Instant 对象调用 toEpochMilli() 方法即可：
- 它只截断纳秒部分，**不四舍五入**，而是向下取整到毫秒（即丢弃 0–999 微秒）
- 例如：
Instant.parse("2023-01-01T12:34:56.789123456Z").toEpochMilli()返回 1672576496789（末三位 789 来自毫秒部分，123456 纳秒被丢弃） - 必须确保 Instant 是非 null，否则抛出 NullPointerException
常见获取 Instant 的方式
多数场景需要先获得 Instant，再转毫秒：
-
当前时间：
Instant.now().toEpochMilli() -
指定字符串解析：
Instant.parse("2024-05-20T10:00:00Z").toEpochMilli()（注意时区必须是 Z 或带偏移） -
从 LocalDateTime + ZoneId 转换：
localDateTime.atZone(ZoneOffset.UTC).toInstant().toEpochMilli()
注意时区与精度陷阱
toEpochMilli() 基于 UTC 时间线，和系统本地时区无关，但输入 Instant 的来源容易出错：
立即学习“Java免费学习笔记（深入）”；
- 不要用
new Date().toInstant().toEpochMilli()—— Date 本身也基于 UTC，虽可行但冗余 - 避免误用
System.currentTimeMillis()直接替代：两者值相等，但语义不同（前者是逻辑时间点，后者是系统时钟快照） - 若需秒级时间戳，用 getEpochSecond()；若需纳秒级，用 toEpochNano()（需 Java 9+）
对比其他常用时间戳方法
同一时刻不同 API 的输出可能不同，关键看起点和精度：
-
System.currentTimeMillis()：long，毫秒，等价于Instant.now().toEpochMilli() -
Instant.now().getEpochSecond() * 1000：仅秒级精度，丢失毫秒，结果可能比 toEpochMilli() 小 0–999 -
LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant().toEpochMilli()：受本地时区影响，不推荐用于统一时间戳生成
