LocalDateTime 表示无时区的本地日期时间，适用于业务计划等无需跨时区场景；Instant 表示 UTC 时间戳，是记录事件真实时刻的唯一推荐类型，两者须通过 ZoneId 安全转换。
LocalDateTime 和 Instant 是 JDK8 新日期时间 API 中两个核心类，用途不同、不可互换，选错会导致时区错误或逻辑异常。
LocalDateTime：本地日期时间，无时区信息
LocalDateTime 表示“某个日历系统下的年月日时分秒”，比如“2023-10-05 14:30:45”，但它不包含时区（ZoneId）或时间偏移（Offset），也不代表一个真实的时刻（instant）。它只是“挂历上的一个时间点”，脱离上下文无法转换成统一的时间戳。
常见用法：
- 表示业务场景中的“计划时间”“预约时间”“报表周期”等无需跨时区比较的场景，例如“每月5号上午9点执行任务”
- 与 DateTimeFormatter 配合做字符串解析和格式化（如 "yyyy-MM-dd HH:mm:ss"）
- 不能直接用于记录事件发生时间（如日志打点、数据库写入），因为它无法还原成统一时刻
⚠️ 注意：LocalDateTime.now() 返回的是 JVM 默认时区的本地时间，但对象本身不含时区——它只是把当前时刻“按本地规则”拆解成了年月日时分秒，丢失了原始偏移信息。
Instant：精确到纳秒的绝对时间点
Instant 表示自 1970-01-01T00:00:00Z（UTC）以来的纳秒数，是时区无关的、全球统一的时间轴坐标。它是记录事件真实发生时刻的唯一推荐类型。
常见用法：
- 记录日志时间、数据库 created_time / updated_time 字段（配合 JDBC 4.2+ 的 setObject(…, Instant)）
- 系统间时间比对、超时判断、缓存过期计算（如 Instant.now().plusSeconds(30)）
- 与 ZoneId 或 OffsetDateTime 转换，获得某一时区下的本地时间（如 instant.atZone(ZoneId.of("Asia/Shanghai"))）
✅ Instant.now() 总是基于系统时钟 + UTC，结果稳定可比；而 LocalDateTime.now() 的含义依赖默认时区，迁移服务器可能出问题。
两者如何安全转换？
它们之间不能直接强转，必须通过时区（ZoneId）或偏移量（ZoneOffset）作为桥梁：
- LocalDateTime → Instant：需指定所属时区，例如 localDateTime.atZone(ZoneId.systemDefault()).toInstant()
- Instant → LocalDateTime：需明确要转成哪个时区的本地时间，例如 instant.atZone(ZoneId.of("Europe/London")).toLocalDateTime()
- 若仅用 instant.toString()，输出为 ISO-8601 格式（含 Z），而 localDateTime.toString() 不含时区，二者字符串不可直接互转
❌ 错误示范：LocalDateTime.from(instant) 会抛 DateTimeException，因为 Instant 没有时区上下文，无法推断“该对应哪一地的本地时间”。
数据库与序列化注意事项
JDBC 4.2+ 支持直接绑定 Instant 到 TIMESTAMP WITH TIME ZONE（推荐）或 TIMESTAMP（隐式按 JDBC 驱动时区处理）；而 LocalDateTime 对应的是无时区的 TIMESTAMP，容易在跨时区部署时引发数据歧义。
JSON 序列化（如 Jackson）中：
- Instant 默认序列化为 ISO-8601 字符串（如 "2023-10-05T06:30:45.123Z"），语义清晰
- LocalDateTime 默认序列化为 "2023-10-05T14:30:45.123"，缺少时区标识，接收方无法确定其原始上下文
建议：对外接口、持久层、日志时间统一使用 Instant；仅在展示层、业务规则层（如“每周三晚8点提醒”）才用 LocalDateTime，并确保上下文明确。
