LocalDate仅处理纯日期，不能解析含时间的字符串；LocalDateTime需严格匹配日期时间格式，且无时区信息，跨时区场景应优先使用Instant或ZonedDateTime。
LocalDate 和 LocalDateTime 是 Java 8 引入的 java.time 包核心类，它们不可变、线程安全、语义清晰——但直接用错时，往往不是“不工作”，而是“时间对不上”或“抛异常却不知为何”。关键不在会不会创建，而在什么时候该用哪个、怎么解析字符串、如何避开时区陷阱。
LocalDate 只处理日期，不含时间，不能 parse 带时间的字符串
常见错误是拿 "2024-05-20 14:30:00" 去调用 LocalDate.parse()，结果抛 DateTimeParseException：它只认纯日期格式，比如 "2024-05-20" 或 "2024/05/20"（需指定格式器）。
- 默认支持 ISO_LOCAL_DATE（
"2024-05-20"），无需额外格式器 - 若输入是
"20240520"，必须用DateTimeFormatter.ofPattern("yyyyMMdd") - 千万别用
LocalDate.parse("2024-05-20 14:30")—— 它连空格都拒绝，更别说时分秒
LocalDate date = LocalDate.parse("2024-05-20"); // ✅
LocalDate bad = LocalDate.parse("2024-05-20 14:30"); // ❌ DateTimeParseException
LocalDateTime 必须同时含日期和时间，parse 时格式必须严格匹配
LocalDateTime 不带时区，代表“本地日历上的某个时刻”，但它的 parse() 对输入格式极其敏感。用错格式器或传入缺失字段的字符串，立刻失败。
- 默认只识别 ISO_LOCAL_DATE_TIME（
"2024-05-20T14:30:00"），注意中间是T，不是空格 - 若字符串是
"2024-05-20 14:30:00"，必须显式传DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss") - 秒或纳秒缺失？比如
"2024-05-20 14:30"，格式器也得写成"yyyy-MM-dd HH:mm"，否则报错
LocalDateTime dt1 = LocalDateTime.parse("2024-05-20T14:30:00"); // ✅ 默认格式
LocalDateTime dt2 = LocalDateTime.parse("2024-05-20 14:30:00",
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")); // ✅ 显式格式
LocalDateTime dt3 = LocalDateTime.parse("2024-05-20 14:30:00"); // ❌ 报错
从字符串转时间时，别硬套 now() 或 of()，先看原始数据结构
很多 bug 源于“看到日期就用 LocalDate.now()，看到带时间就用 LocalDateTime.now()”，但真实数据来自数据库、API 或日志文件——它们的格式千差万别，硬套会导致解析失败或逻辑错位。
立即学习“Java免费学习笔记（深入）”；
- 数据库字段是
DATE类型（如 MySQL 的DATE），对应LocalDate；是DATETIME或TIMESTAMP，才考虑LocalDateTime（注意：后者不包含时区信息，TIMESTAMP实际含时区语义） - JSON API 返回
"created_at": "2024-05-20"→ 用LocalDate；返回"created_at": "2024-05-20T15:30:45Z"→ 这是带时区的，该用ZonedDateTime或Instant，不是LocalDateTime - 日志里出现
"2024/05/20-14:30:00.123"？得自定义格式器：DateTimeFormatter.ofPattern("yyyy/MM/dd-HH:mm:ss.SSS")
LocalDateTime 不能直接用于跨时区计算，这是最常被忽略的坑
很多人以为 LocalDateTime “能表示时间”就能做加减、比较、存储——但它没有时区上下文。两个 LocalDateTime 对象相减得到的是纯时间差（比如 2 小时），但如果你在东京生成一个 LocalDateTime，又在北京解析同一个字符串，它们字面值一样，实际对应的真实时刻却差 1 小时。
- 存数据库前，如果业务要求精确到毫秒且涉及时区（如预约系统），别存
LocalDateTime，改用Instant或带时区类型 - 和前端交互时，若前端传来
"2024-05-20T14:30:00"，后端用LocalDateTime接收，等于默认按服务器本地时区解释——这在多地域部署时必然出错 - 真正需要“本地日历时间”的场景极少，比如排班表只写“5月20日 14:30 开会”，不关心在哪时区执行；其余绝大多数时间运算、持久化、比较，应优先考虑
Instant或ZonedDateTime
用对 LocalDate 和 LocalDateTime 的前提，不是记住 API，而是先问自己：这个字符串到底表达什么？它是否隐含时区？下游系统怎么理解它？一旦混淆“日历表示”和“真实时刻”，后面所有操作都会漂移。
