Instant.now() 是基于UTC的纳秒级无时区时间戳，直接读取系统高精度时钟，无需本地时间转换；应避免使用 System.currentTimeMillis()，优先用 Instant.toString() 或拆分存储纳秒值，严防日志与序列化中的时区污染。
Instant.now() 就是你要的全球统一时间戳
Instant.now() 返回的是基于 UTC 的纳秒级时间戳，本质是自 1970-01-01T00:00:00Z（即 Unix epoch）以来的精确偏移量，不携带任何时区信息。它不是“本地时间转 UTC”，而是直接从系统高精度时钟读取 UTC 线值 —— 这就是你真正需要的、与时区完全解耦的机器时间。
常见误解是以为要“先获取本地时间再转换”，其实完全没必要。只要系统时钟已同步（NTP），Instant.now() 就是可靠、可比、跨服务一致的时间源。
别用 System.currentTimeMillis() 替代 Instant
System.currentTimeMillis() 虽然也返回 UTC 毫秒值，但它有三个硬伤：
- 精度仅限毫秒，丢失微秒/纳秒信息，对高并发日志、分布式追踪、性能采样不够用
- 底层依赖
System.nanoTime()和System.currentTimeMillis()的混合实现，某些 JVM（如旧版 OpenJDK）在时钟调整时可能出现回跳或跳跃 - 类型是
long，语义模糊；而Instant是不可变值对象，自带解析、比较、序列化能力，且能无缝对接java.time生态（如Duration、ZonedDateTime）
序列化和存储时，坚持用 ISO-8601 字符串或纳秒长整型
写入数据库或发往下游服务时，避免隐式 toString() 或只存毫秒数：
- ✅ 推荐：用
instant.toString()→ 输出形如"2024-05-22T14:36:08.123456789Z"，标准、可读、无歧义、支持毫秒级以上精度 - ✅ 推荐：用
instant.getEpochSecond()和instant.getNano()分开存两个字段，或组合为instant.toEpochMilli()（仅当接受毫秒精度损失时） - ❌ 避免：
new Date(instant.toEpochMilli())包装后再 toString() —— 引入Date就可能触发默认时区格式化，破坏时区无关性 - ❌ 避免：直接
String.valueOf(instant.getEpochSecond())—— 丢掉纳秒部分，且字符串不可直接解析回Instant
警惕日志框架和 JSON 库的自动时区注入
很多日志框架（Logback、Log4j2）或 JSON 库（Jackson）在格式化 Instant 时，默认会套上本地时区或 JVM 默认时区，输出类似 "2024-05-22T22:36:08.123+08:00" —— 这看起来像带时区，但其实原始 Instant 本身没变，只是显示被污染了。
解决方法：
- Jackson：注册
JavaTimeModule并设置SerializationFeature.WRITE_DATES_AS_TIMESTAMPS为false，再配置Instant的序列化器强制输出 ISO-8601 Z 结尾格式 - Logback：在
%d{ISO8601_OFFSET_DATE_TIME_HHC_M}类似 pattern 中，改用%d{ISO8601_BASIC_OFFSET_DATE_TIME}并确保DateTimeFormatter显式指定ZoneOffset.UTC - 最稳妥：日志中直接打印
instant.toString()，不依赖框架格式化
真正难的不是获取 Instant，而是守住它从生成到落盘、传输、展示的每一步都不被时区逻辑意外污染 —— 尤其在多 JVM、多语言混布的系统里，一个环节的隐式转换就足以让时间对比失效。
