localdatetime.parse() 解析失败主因是默认仅支持 iso_local_date_time 格式，需显式传入 datetimeformatter；大小写敏感、时区信息丢失、未复用 formatter 也是常见问题。
LocalDateTime.parse() 解析字符串失败的常见原因
直接用 LocalDateTime.parse() 读字符串，十次有八次抛 DateTimeParseException。根本原因不是 API 有问题，而是它默认只认 ISO_LOCAL_DATE_TIME 格式（比如 "2023-10-05T14:30:45"），遇到中文、空格、斜杠、无 T 分隔符就立刻报错。
- 常见错误现象：
Text '2023/10/05 14:30:45' could not be parsed at index 4 - 必须显式传
DateTimeFormatter，不能依赖默认行为 - 别用
SimpleDateFormat的习惯去套——LocalDateTime不接受 pattern 字符串直传，必须先构造 formatter - 推荐写法：
LocalDateTime.parse("2023/10/05 14:30:45", DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss"))
DateTimeFormatter.ofPattern() 中的转义与特殊字符
写自定义格式时，字母大小写敏感，且部分字符需转义，否则解析会静默出错或结果错乱。比如年份用 yyyy，误写成 YYYY 可能返回错误的周基准年；mm 是分钟，MM 才是月份。
- 常见坑：
"yyyy-MM-dd hh:mm:ss"里的hh是 12 小时制，若源数据是 24 小时制（如"15:30:00"），必须改用HH - 空格、斜杠、冒号等非字母符号无需转义；但字母如
L（本地月份缩写）、E（星期）需注意区域设置影响 - 要输出文字内容（如 “at”、“UTC”），得用单引号包裹：
"yyyy-MM-dd 'at' HH:mm:ss" - 预定义常量如
DateTimeFormatter.ISO_LOCAL_DATE_TIME安全但僵硬，业务中多数情况仍需自定义
LocalDateTime 转 String 时丢失时区信息的风险
LocalDateTime 本身不含时区，调用 .toString() 或用 formatter 格式化，结果永远只是“本地时刻”的文本表示。如果原始数据来自不同时区（比如前端传来的 UTC 时间戳），直接 parse 成 LocalDateTime 再格式化，等于主动丢弃时区上下文。
- 典型场景：后端接收前端发来的
"2023-10-05T08:00:00Z"（UTC），用LocalDateTime.parse()解析后变成2023-10-05T08:00—— 它现在被当成“系统默认时区的早上八点”，而非“UTC 的早上八点” - 正确做法：先用
ZonedDateTime.parse()或Instant.parse()保留时区语义，再按需转换为指定时区的LocalDateTime - 如果确定输入就是“无时区的本地时间”（如用户填写的生日、预约时间），那用
LocalDateTime没问题；但凡涉及系统间时间传递，优先考虑Instant或ZonedDateTime
性能敏感场景下复用 DateTimeFormatter 实例
DateTimeFormatter 是线程安全的不可变对象，但每次调用 ofPattern() 都会新建实例。高并发解析（比如日志时间字段提取）下，频繁创建 formatter 会增加 GC 压力。
立即学习“Java免费学习笔记（深入）”；
- 务必把 formatter 提取为
static final字段，例如：private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); - 不要在方法内临时 new，也不要为每个请求 new 一个
- 注意：
DateTimeFormatter不支持运行时修改 pattern，所以复用完全安全 - 如果 pattern 来自配置或用户输入，无法静态化，至少缓存到
ConcurrentHashMap中，避免重复编译
