instant.now()生成的是utc时间戳，不依赖本地时区，全球各地调用结果一致；其tostring()输出末尾的z即表示utc，instant本身无时区概念。
Instant.now() 生成的是 UTC 时间戳，不是本地时区时间
很多人误以为 Instant.now() 返回的是“当前系统时间”，其实它返回的是从 Unix 纪元（1970-01-01T00:00:00Z）开始的纳秒偏移量，**天然就是 UTC 时间戳**，不依赖本地时区设置。这意味着你在东京、纽约或上海调用它，得到的值完全一致——只要系统时钟准确。
常见错误现象：
• 把 Instant.now().toString() 的输出（如 "2024-06-15T08:32:15.123Z"）误认为是“带 Z 的字符串才叫 UTC”，其实 Z 只是格式化后的表示，Instant 本身没有时区概念；
• 用 LocalDateTime.now() 或 ZonedDateTime.now() 替代，结果引入了本地时区偏差。
实操建议：
• 直接使用 Instant.now() 获取高精度 UTC 时间戳；
• 存储到数据库时，优先选支持 TIMESTAMP WITH TIME ZONE 的字段（如 PostgreSQL），或存为 BIGINT 类型的纳秒值（instant.toEpochMilli() 或 instant.getNano() 组合）；
• 不要手动加减时区偏移（如 +8 小时），Instant 本就不该被“转换”成某地“当前时间”再处理。
解析 ISO 8601 字符串时，注意末尾 Z 和 ±hh:mm 的区别
Instant.parse() 只接受严格符合 ISO 8601 的 UTC 表达式：必须带 Z，或带显式时区偏移（如 +00:00）。它**拒绝无时区信息的字符串**（例如 "2024-06-15T08:32:15"），也**不接受非零偏移的本地时间字符串直接转 Instant**（如 "2024-06-15T16:32:15+08:00" 会报错）。
常见错误现象：
• 传入前端送来的 "2024-06-15T16:32:15+08:00" 给 Instant.parse()，抛出 DateTimeParseException；
• 用 LocalDateTime.parse() 解析后再“硬塞”进 Instant，导致逻辑错误。
实操建议：
• 前端应统一发送带 Z 的 UTC 字符串（如 "2024-06-15T08:32:15.123Z"），后端直接 Instant.parse()；
• 若必须处理带偏移的字符串（如 "+08:00"），先用 OffsetDateTime.parse()，再调用 .toInstant() 转换；
• 避免用 SimpleDateFormat 或自定义 pattern 解析，它无法安全处理时区语义。
与数据库交互时，JDBC 驱动版本影响 Instant 支持质量
Java 8+ 的 java.time.Instant 在 JDBC 层并非“开箱即用”。低版本驱动（如 MySQL Connector/J 5.1.x、PostgreSQL JDBC 42.2.5 之前）对 setObject(…, Instant.class) 支持不完整，可能静默转成本地时区时间再写入，造成数据偏移。
常见错误现象：
• 写入 Instant.ofEpochSecond(1718440335)（对应 UTC 2024-06-15T08:32:15Z），查出来却是 2024-06-15T16:32:15Z（+8 小时）；
• 使用 PreparedStatement.setTimestamp(idx, Timestamp.from(instant))，但 Timestamp 构造函数隐式绑定 JVM 默认时区。
实操建议：
• 升级到 MySQL Connector/J 8.0+ 或 PostgreSQL JDBC 42.2.5+；
• 写入时优先用 ps.setObject(idx, instant)，而非 Timestamp；
• 读取时用 rs.getObject(idx, Instant.class)，不要用 getTimestamp()；
• 若驱动不支持，退而求其次：存为 long（毫秒值），应用层自行构造 Instant.ofEpochMilli(...)。
跨服务传递 Instant 时，JSON 序列化默认行为容易丢精度
Jackson 默认把 Instant 序列化为秒级时间戳（long），丢失毫秒/纳秒精度；Gson 更激进，默认只输出秒级字符串（如 "2024-06-15T08:32:15Z"），连毫秒都砍掉。
常见错误现象：
• A 服务生成 Instant.now()（含纳秒），经 JSON 传给 B 服务后变成秒级，多次传递后误差累积；
• 前端用 Date.parse() 解析 Jackson 输出的数字时间戳，但没考虑它是秒还是毫秒，导致时间错乱。
实操建议：
• Jackson：注册 JavaTimeModule 并启用 WRITE_DATES_AS_TIMESTAMPS = false，确保输出 ISO 字符串；
• Gson：用 new GsonBuilder().registerTypeAdapter(Instant.class, new InstantTypeAdapter()).create()，其中 InstantTypeAdapter 显式调用 instant.toString()；
• 更稳妥的方式：协议层约定统一用 ISO 8601 字符串（带毫秒和 Z），禁止传输纯数字时间戳。
