localdate仅处理无时区日期，localdatetime含日期时间但无时区；二者均不可变且线程安全，但误用易致datetimeexception或时区错误；涉及真实时刻须用instant或zoneddatetime。
LocalDate 和 LocalDateTime 是 Java 8 引入的 java.time 包核心类，它们不可变、线程安全、语义清晰——但直接用错时容易抛 DateTimeException 或得到意外的时区/时分秒值。
LocalDate 只处理日期，不带时间也不带时区
它适合表示生日、合同生效日、报表统计日这类纯日期场景。一旦你调用 now()，拿到的是系统默认时区当天的日期（注意：不是 UTC）；若跨时区协作，必须显式传入 ZoneId 或用 Instant 转换。
-
LocalDate.now()依赖 JVM 默认时区，测试环境和生产环境时区不一致会导致结果不同 - 不能直接和
long时间戳互转，需经atStartOfDay(ZoneId)→Instant→toEpochMilli() -
字符串解析必须匹配格式，
LocalDate.parse("2023-10-5")会失败，得用DateTimeFormatter.ofPattern("yyyy-M-d")
LocalDateTime 包含日期+时间，仍无时区概念
它本质上是“本地日历上的一个挂钟读数”，比如会议室预约表里写的“2024-06-15 14:00”，不代表任何绝对时刻。误把它当时间戳存数据库、或用于计算时间差，常导致逻辑错误。
- 构造时若用
LocalDateTime.now()，返回的是系统默认时区当前时刻的“年月日时分秒”快照，但丢弃了时区信息 - 和
Instant互转必须指定ZoneId，例如localDateTime.atZone(ZoneId.systemDefault()).toInstant() - 做加减运算（如
plusDays(1)）没问题，但跨夏令时边界时不会自动调整——它只机械地加减字段
什么时候该用 ZonedDateTime 或 Instant 而不是 LocalDateTime
只要涉及“这个事件在地球上某处真实发生过”，就必须带时区上下文。比如用户下单时间、服务器日志时间戳、定时任务触发点。
立即学习“Java免费学习笔记（深入）”；
- 存数据库时间字段（如 MySQL 的
TIMESTAMP）应优先用Instant，而不是LocalDateTime，否则 JDBC 驱动可能按本地时区隐式转换 - 对外 API 返回时间字段，推荐用 ISO 8601 字符串（如
"2024-06-15T14:30:00Z"），对应 Java 中用Instant.toString()，而非LocalDateTime.toString() - 如果业务强依赖某个固定时区（如“北京时间每天上午9点发通知”），用
ZonedDateTime.of(localDateTime, ZoneId.of("Asia/Shanghai"))，别用LocalDateTime硬编码
LocalDateTime now = LocalDateTime.now();
LocalDateTime tomorrow = now.plusDays(1);
// ✅ 合法：纯字段运算
Instant instant = now.atZone(ZoneId.systemDefault()).toInstant();
// ✅ 必须带 ZoneId 才能转成绝对时刻
LocalDateTime dbValue = resultSet.getObject("create_time", LocalDateTime.class);
// ⚠️ 危险：MySQL 的 DATETIME 类型不存时区，JDBC 会按客户端时区解释，建议改用 getObject(..., Instant.class)
最容易被忽略的是：LocalDateTime 不是“本地时间”，而是“无时区的时间”；它的“本地”仅指日历系统（ISO），不指地理时区。跨系统传输或持久化前，务必确认是否已丢失上下文。
