Instant.now() 返回的是自 Unix 纪元（1970-01-01T00:00:00Z）起的纳秒级UTC时间戳，是无时区、纯机器时间坐标，不随系统时区改变，也不代表本地日历时间。
Instant.now() 返回的是什么时间？
它返回的是从 Unix 纪元（1970-01-01T00:00:00Z）开始的纳秒级偏移量，本质是纯机器时间戳，不含时区、不含日历含义，也不受系统本地时区影响。
- 即使你把系统时区改成
Asia/Shanghai，Instant.now()的值和 UTC 时间完全一致 - 它不是“当前北京时间”，也不是“当前系统显示时间”——只是那一刻的全球统一坐标点
- 常见误解：用
Instant.now().toString()看到2024-05-22T08:30:45.123Z就以为是本地时间，其实末尾的Z表示就是 UTC，不是你的本地时区
把 Instant 转成北京时间（CST）该用哪个类？
必须经过 ZoneId 和 ZonedDateTime 或 LocalDateTime 中转，不能直接格式化或强转。
-
Instant本身没有format()方法，也没有getYear()这类日历操作接口 - 正确路径是：
instant.atZone(ZoneId.of("Asia/Shanghai"))→ 得到ZonedDateTime→ 再调用toLocalDateTime()或直接format() - 别用
new Date(instant.toEpochMilli())+SimpleDateFormat，那是过时且线程不安全的老路，还可能因系统默认时区出错
为什么 Instant.parse("2024-05-22T08:30:45") 会报 DateTimeParseException？
因为 Instant.parse() 只接受带时区信息（或 Z）的 ISO 8601 字符串，纯日期时间字符串不合法。
- ✅ 合法：
Instant.parse("2024-05-22T08:30:45Z")、Instant.parse("2024-05-22T08:30:45+00:00") - ❌ 非法：
Instant.parse("2024-05-22T08:30:45")、Instant.parse("2024-05-22 08:30:45") - 如果只有无时区字符串，得先用
LocalDateTime.parse()，再指定时区转成Instant：localDateTime.atZone(ZoneId.of("UTC")).toInstant()
存数据库时用 Instant 还是 LocalDateTime？
取决于字段语义。记录“事件发生的真实时刻”，必须用 Instant；记录“用户填写的本地时间（如预约时间）”，才用 LocalDateTime。
立即学习“Java免费学习笔记（深入）”；
- JDBC 4.2+ 支持直接绑定
Instant到TIMESTAMP WITH TIME ZONE字段，PostgreSQL/Oracle 推荐这么用 - MySQL 的
TIMESTAMP类型底层存的是 UTC，但驱动默认按 JVM 时区转换，容易引发隐式偏差；稳妥做法是显式用PreparedStatement.setObject(idx, instant) - 千万别把
LocalDateTime直接塞进需要时区语义的字段——它没时区信息，数据库无法知道你指的到底是东京时间还是纽约时间
Instant.now()，而是每次做转换时，脑子里得清楚当前这个值代表的是「物理时刻」还是「日历表达」。漏掉一次 atZone()，或者错选了 ZoneId.systemDefault()，时间就悄悄漂移了。 
