datetimeformatter的核心作用是格式化时间对象为字符串及解析字符串为时间对象，是java 8后线程安全的唯一推荐方案，替代了不安全的simpledateformat。
DateTimeFormatter 的核心作用就两个：**把 LocalDate、LocalDateTime 等时间对象转成字符串（格式化）**，以及**把符合规则的字符串还原成时间对象（解析）**。它不是装饰用的工具类，而是 Java 8 之后处理时间 ↔ 字符串转换的**唯一推荐入口**——替代了线程不安全又难维护的 SimpleDateFormat。
为什么必须用 DateTimeFormatter 而不是 SimpleDateFormat？
这不是“升级可选”，而是实际工程中的硬性要求：
-
SimpleDateFormat是可变对象，多线程共用一个实例时，parse()或format()极易因内部状态混乱抛出java.lang.NumberFormatException或返回错误时间（比如把 "2025-12-30" 解析成 1970 年） -
DateTimeFormatter是不可变（immutable）且线程安全的，定义一次可全局静态复用，无同步开销 - 错误提示更精准：例如用
yyyy-MM-dd去解析"2025/12/30"，会明确报错Text '2025/12/30' could not be parsed at index 4，直接定位到斜杠位置
三种创建方式怎么选？
别一上来就写 ofPattern —— 先看是否已有现成方案：
-
ISO 标准格式（最常用）：直接用预定义常量，零配置、无需记忆模式字母
LocalDateTime.parse("2025-12-30T08:54:12", DateTimeFormatter.ISO_LOCAL_DATE_TIME) -
本地化风格（如中文星期、月份）：用
ofLocalizedDateTime+Locale，避免手写 “年/月/日”DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM).withLocale(Locale.SIMPLIFIED_CHINESE) -
自定义格式（如日志、API 返回）：必须用
ofPattern，注意大小写敏感：MM是月，mm是分；HH是 24 小时制，hh是 12 小时制DateTimeFormatter.ofPattern("yyyy年MM月dd日 HH:mm:ss")
解析字符串时最容易踩的坑
看似简单，但 80% 的 DateTimeParseException 都源于这几点：
-
模式与字符串不严格匹配：比如模式是
"yyyy-MM-dd"，但字符串是"2025-12-30 "（末尾有空格），会直接失败 —— 解析前建议先trim() -
忽略 Locale 导致中文解析失败：用
ofPattern("yyyy年MM月dd日")解析"2025年12月30日"时，若未显式传入Locale.SIMPLIFIED_CHINESE，在某些 JVM 默认语言环境下可能识别不了“年/月/日” -
类型错配：拿
LocalDateTime.parse(...)去解析只有日期的字符串（如"2025-12-30"），会报错；应改用LocalDate.parse(...)+DateTimeFormatter.ISO_LOCAL_DATE
LocalDateTime now = LocalDateTime.now();
// ✅ 正确：静态复用，线程安全
static final DateTimeFormatter LOG_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS");
String logTime = now.format(LOG_FORMATTER); // "2025-12-30 08:54:12.345"
LocalDateTime parsed = LocalDateTime.parse("2025-12-30 08:54:12.345", LOG_FORMATTER);
真正麻烦的从来不是写对一行 ofPattern，而是在跨系统、跨语言、跨时区场景下，确保格式器能稳定扛住各种输入变体——所以别省那几行 trim() 和 withLocale()。 
