datetimeparseexception 是 java 8 时间 api 中因格式或语义不匹配导致的运行时异常，如用 yyyy-mm-dd 解析 "2023/04/01" 或非法日期 "2023-02-30"；它零容忍、不自动修正，需预设多格式尝试解析，并显式处理 locale、时区及业务容错规则。
DateTimeParseException 是什么错误
它不是你写错了语法，而是 DateTimeFormatter 和实际字符串对不上号时抛出的运行时异常。比如用 yyyy-MM-dd 去解析 "2023/04/01"，或者解析 "2023-02-30" 这种不存在的日期，都会触发这个异常。
Java 8 的时间 API 默认零容忍——不自动修正、不模糊匹配、不 fallback 到默认值。一旦格式或语义不符，直接炸。
怎么安全地解析不确定格式的日期字符串
别硬扛
DateTimeParseException</p> <p>常见做法是预设多个 <code>DateTimeFormatter，逐个试；但要注意顺序和性能：
立即学习“Java免费学习笔记（深入）”；
- 优先放最常用、最严格的格式（比如
ISO_LOCAL_DATE），避免低效遍历 - 避免用
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS")去匹配可能缺毫秒的字符串——宁可先截断再试 - 对用户输入类场景，建议先 trim + 长度校验，过滤明显非法输入（如空、纯字母）再进解析流程
示例：尝试两种常见格式
String input = "2023-04-01";
LocalDate date = null;
for (DateTimeFormatter f : Arrays.asList(DateTimeFormatter.ISO_LOCAL_DATE, DateTimeFormatter.ofPattern("dd/MM/yyyy"))) {
try {
date = LocalDate.parse(input, f);
break;
} catch (DateTimeParseException e) {
continue;
}
}
为什么不用 parseUnresolved 或 lenient 模式
parseUnresolved 不解决你的问题——它只是跳过解析失败的部分，返回一个不完整的 TemporalAccessor，你仍需手动提取字段，且无法保证语义正确（比如把 "2023-13-01" 解成 January？）
lenient 模式在 DateTimeFormatter 中并不存在；旧 API（SimpleDateFormat）的 setLenient(true) 会把 2023-02-30 自动转成 2023-03-02，但 Java 8 的新 API 彻底移除了这种“智能纠错”，因为不可控、难测试、易埋坑。
所以别找捷径，容错逻辑得你自己写清楚：允许哪些变形？是否接受缺失部分（如无时间）？是否接受分隔符替换？这些都要明确定义。
容易被忽略的时区和本地化陷阱
同一个字符串，在不同 Locale 下可能解析失败或结果不同：
-
DateTimeFormatter.ofPattern("MMM dd yyyy").withLocale(Locale.US)能解析"Apr 01 2023"，换成Locale.CHINA就报错 - 没显式指定
ZoneId时，ZonedDateTime.parse()依赖系统默认时区，测试机和生产机不一致会导致偶发失败 - 用
DateTimeFormatter.ISO_OFFSET_DATE_TIME解析"2023-04-01T12:00:00Z"没问题，但解析"2023-04-01T12:00:00+08:00"也 OK；可一旦遇到"2023-04-01T12:00:00+08"（缺冒号），就直接DateTimeParseException
真实项目里，输入来源不可控时，必须把 locale、时区、格式变体都列成配置项，而不是写死在代码里。
解析失败不是终点，而是你该定义业务规则的起点——哪几种错可以忽略？哪几种必须告警？哪些要记录原始字符串留痕？这些比“怎么 catch 异常”重要得多。
