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 —— 先看是否已有现成方案：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
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()。 
