DateTimeFormatter.ofPattern() 不支持模糊匹配或可选字段，必须严格匹配输入字符串与模式的长度、分隔符和占位符；多种格式需预处理或多个formatter尝试解析，且pattern中中文字符须用单引号包裹并指定Locale。
DateTimeFormatter.ofPattern() 不支持模糊匹配或可选字段
Java 的 DateTimeFormatter.ofPattern() 本质是严格按模式字符串逐字符解析的，它不会跳过缺失部分、也不会尝试“猜测”你省略的是年还是时分秒。比如你传入 "2023-04-15" 却用模式 "yyyy-MM-dd HH:mm:ss"，会直接抛 DateTimeParseException —— 它不补零，也不忽略后缀。
常见错误现象：Text '2023-04-15' could not be parsed at index 10（卡在空格位置），或者更隐蔽地，在解析带毫秒但格式没写 SSS 时静默截断。
- 必须确保输入字符串与 pattern 完全对齐：长度、分隔符、占位符数量都得一致
- 如果原始数据有多种格式（如有时带时间、有时只有日期），不能靠一个 pattern 解决，得预处理或用多个 formatter 尝试
-
ofPattern()不接受正则、通配符或条件语法，所谓“非标准”只能靠组合已有的字母模式实现，比如用uuuu替代yyyy处理 0001–0099 年份
用单字母模式控制世纪、时区、毫秒等易错细节
看似简单的 "yyyy-MM-dd" 其实暗藏兼容性陷阱。比如 yyyy 在 1–999 年间可能被解释为 AD 1–999，而 uuuu 才保证 ISO 周年历语义；HH 是 0–23，hh 是 1–12（需搭配 a AM/PM）；SSS 是毫秒，但若输入是微秒级字符串（如 "123456"），它只会取前三位。
典型使用场景：解析日志时间戳 "2023-04-15T14:30:22.123Z"
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSX");
-
'T'是字面量单引号包裹，不是变量 -
X解析单字母时区（Z→ 0，+08→ 8），而xxx才支持+08:00格式 - 毫秒部分必须写成
SSS，写成S或SS会导致解析失败或数据丢失 - 如果日志里时区有时是
Z、有时是+0800，一个 pattern 搞不定，得拆成两个 formatter 分别 try-catch
解析含中文或自定义文本的日期字符串
像 "2023年04月15日 14点30分" 这类带中文单位的字符串，不能靠简单替换字母模式解决。Java 默认 locale 下，yyyy年MM月dd日 中的“年”“月”“日”会被当作字面量，但前提是它们在 pattern 里也用单引号包裹，否则会报错。
正确写法：
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy'年'MM'月'dd'日' HH'点'mm'分'", Locale.CHINA);
- 所有中文字符必须用单引号
'包裹，否则解析器会当成未知模式字母报Unsupported field: DayOfYear类错误 - 必须显式传入
Locale.CHINA，否则中文星期、月份名无法识别（比如“星期一”） - 如果字符串中“点”“分”偶尔缺失（如只有
"2023年04月15日"），同样会失败 —— 没有“可选段落”机制 - 替代方案：先用
String.replace()把中文替换成英文或符号，再走标准 pattern，比硬啃 locale 更可控
性能和线程安全要注意的冷知识
DateTimeFormatter 是 immutable 且线程安全的，但 ofPattern() 每次调用都会新建对象。如果在循环里反复写 DateTimeFormatter.ofPattern("...")，GC 压力不小，尤其高并发解析日志时。
- 务必把 formatter 提取为
static final字段复用，哪怕 pattern 看起来很简单 - 不要为了“动态拼接 pattern”而在运行时频繁调用
ofPattern()，pattern 字符串本身应是编译期常量 - 如果真要支持运行时 pattern 变化（比如用户自定义格式），缓存
ConcurrentHashMap<string datetimeformatter></string>，但注意 key 要标准化（trim、去空格、统一大小写） - pattern 字符串里多一个空格、少一个单引号，都会导致新对象生成，看似无害，实则悄悄吃内存
真正难的从来不是写出一个能跑的 pattern，而是想清楚：输入数据到底有多少种变体、哪些差异能靠 pattern 消化、哪些必须前置清洗、哪些根本没法用 ofPattern() 覆盖——这些边界往往在上线后第一波脏数据进来时才暴露。
