选 LocalDate 还是 LocalDateTime 取决于业务是否需要时间信息：只关心日期用 LocalDate，需精确到时刻用 LocalDateTime；二者均无时区，不能直接表示绝对时间，跨时区场景应优先使用 Instant。
选 LocalDate 还是 LocalDateTime，关键看业务是否需要时间（时分秒）信息。只关心日期（比如生日、合同生效日、统计报表的“某天”），用 LocalDate；需要精确到时刻（比如订单创建时间、日志打点、定时任务触发点），必须用 LocalDateTime。
LocalDate：纯日期，无时区、无时间
LocalDate 表示一个不带时间、不带时区的日期，例如 “2024-05-20”。它内部只存年、月、日三个字段，内存占用小，比较和计算也更轻量。
- 适合场景：生日校验、法定节假日判断、按天汇总数据、数据库中 date 类型字段映射
- 常见操作：plusDays(1)、isBefore(other)、withYear(2025)，都只影响日期部分
- 注意：不能直接转成时间戳，也不能参与涉及“时刻”的计算（如两个 LocalDate 相减得到的是 Period，不是 Duration）
LocalDateTime：日期 + 时间，仍无时区
LocalDateTime 是 LocalDate 和 LocalTime 的组合，表示“本地的一个具体时刻”，例如 “2024-05-20T14:30:45”。它不含时区信息，因此不代表全球统一的时间点（比如它无法回答“此刻在东京是几点”）。
- 适合场景：系统内部记录事件发生时间（只要不跨时区）、缓存过期时间、数据库中 datetime 或 timestamp（无时区）字段映射
- 常见操作：plusHours(2)、truncatedTo(ChronoUnit.MINUTES)、atZone(ZoneId.systemDefault())（后续可转为带时区的 ZonedDateTime）
- 注意：不能直接用于跨时区调度或存储为“绝对时间”——必须配合 ZoneId 使用才能转换为 Instant
别混淆：它们都不代表“真实世界中的某个瞬间”
LocalDate 和 LocalDateTime 都缺少时区上下文，所以不能直接转换为 Unix 时间戳（Instant）。强行用 atStartOfDay(ZoneId) 转换，结果依赖你传入的 ZoneId —— 同一个 LocalDateTime 在东八区和西五区对应完全不同的 Instant。
立即学习“Java免费学习笔记（深入）”；
- 要保存/传输/比较绝对时间？优先用 Instant
- 要展示给用户看？用 LocalDateTime 或 LocalDate + 显式时区格式化（如 DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm").withZone(ZoneId.of("Asia/Shanghai"))）
- 数据库交互：确认字段类型——date → LocalDate，datetime/timestamp without time zone → LocalDateTime，timestamp with time zone → OffsetDateTime 或 Instant
一个典型误用：把 LocalDateTime 当作服务器当前时刻存库
写法：LocalDateTime.now() 存入数据库的 datetime 字段，看似没问题。但若应用部署在多时区服务器，或数据库时区设置不一致，会导致“同一逻辑时刻”在不同环境读出来不一样。
- 更稳妥做法：用 Instant.now() 存为 UTC 时间戳，读取时再按需转为用户所在时区的 LocalDateTime 展示
- 如果坚持用 LocalDateTime，请确保全链路（JVM、数据库、连接驱动）时区统一（如全部设为 UTC），并明确文档说明这是“系统本地时间”而非“用户本地时间”
