DateFormat.parse() 会抛出 ParseException 怎么办
直接调用 parse() 是最常见出错点：它不处理格式不匹配、空字符串、null 或时区歧义，一律扔 ParseException。别指望它自动容错。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远用
try-catch包住parse()，且不要只 catchException—— 明确捕获ParseException - 提前校验输入：
str == null || str.trim().isEmpty()，避免传入空值触发无意义异常 - 如果字符串可能含时区（如
"2023-10-05T14:30:00+0800"），SimpleDateFormat默认不支持，得换DateTimeFormatter（Java 8+）
SimpleDateFormat 线程不安全，多线程下怎么用
SimpleDateFormat 实例不是线程安全的 —— 多个线程共用同一个实例，解析结果可能错乱，甚至返回错误日期或抛 ArrayIndexOutOfBoundsException。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个线程创建独立实例：开销不大，最稳妥
- 用
ThreadLocal<simpledateformat></simpledateformat>缓存，避免重复 new，例如：private static final ThreadLocal<simpledateformat> df = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"))</simpledateformat> - Java 8+ 强烈推荐改用
DateTimeFormatter（不可变、线程安全），配合LocalDate.parse()或ZonedDateTime.parse()
格式字符串里 "YYYY" 和 "yyyy" 差在哪
用错年份模式是隐形坑：在周基准场景下，YYYY 是“基于周的年”（ISO week year），yyyy 才是日历年。比如 2023-12-31 是周日，属于 2024 年第 1 周，YYYY 会解析成 2024。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 99% 场景都该用
yyyy；只有明确要按 ISO 周对齐时才用YYYY - 月份必须用
MM（大写），mm是分钟，写成"yyyy-mm-dd"会导致日期全乱 - 24 小时制用
HH，12 小时制用hh，混用会解析出错时间（比如把 14 点当成凌晨 2 点）
解析后 Date 对象的时区到底按谁的算
Date 本身不存时区，只存毫秒数（自 1970-01-01 UTC 起）。但 SimpleDateFormat 解析时会按其 TimeZone 把字符串“解释”为对应时刻 —— 这个时区默认是 JVM 启动时的系统时区，不是字符串里的时区（除非你显式设置了）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 解析前务必调用
setTimeZone(TimeZone.getTimeZone("UTC"))或其他明确时区，否则本地时区变化（如夏令时切换）会让结果漂移 - 字符串自带时区偏移（如
"2023-10-05 12:00:00+0900"）时，SimpleDateFormat默认忽略它；必须手动设置时区或改用ZonedDateTime.parse() - 如果业务要求严格时区语义，别碰
Date+SimpleDateFormat组合，直接上Instant/ZonedDateTime
真正麻烦的从来不是“怎么写出来”，而是“为什么这次对、下次就错”——时区、线程、格式字母大小写、异常边界，四个点漏一个，parse() 就能给你演一出随机剧。
