LocalTime.parse仅解析纯时间字符串（如"10:15:30"），不支持含日期或时区的ISO字符串；解析高精度时间需自定义DateTimeFormatter；推荐复用ISO_LOCAL_TIME格式器。
LocalTime.parse 能直接解析 "10:15:30" 这类字符串，但不能解析带日期的 ISO 字符串
LocalTime.parse 只处理纯时间部分（HH:mm:ss[.SSS]），不接受 "2024-05-20T10:15:30" 或 "2024-05-20 10:15:30" 这类含日期的字符串——它会抛出 DateTimeParseException。
常见错误现象：Text '2024-05-20T10:15:30' could not be parsed at index 0，因为解析器从开头就发现不是合法时间格式。
- 能成功解析的示例：
LocalTime.parse("10:15:30")、LocalTime.parse("14:30:00.123") - 不能解析的示例：
LocalTime.parse("2024-05-20T10:15:30")、LocalTime.parse("10:15:30+08:00") - 若需提取其中的时间部分，得先用
LocalDateTime.parse或ZonedDateTime.parse解析完整字符串，再调用.toLocalTime()
解析带毫秒或纳秒的时间字符串需要显式指定 DateTimeFormatter
默认的 LocalTime.parse(CharSequence) 只支持最多三位毫秒（即 HH:mm:ss.SSS）。遇到 "10:15:30.123456"（微秒）或 "10:15:30.123456789"（纳秒）时，会因格式不匹配失败。
解决方式是传入自定义 DateTimeFormatter：
LocalTime.parse("10:15:30.123456", DateTimeFormatter.ofPattern("HH:mm:ss.SSSSSS"))
- 模式中
S的数量决定接受的精度位数：SSS→ 毫秒，SSSSSS→ 微秒，SSSSSSSSS→ 纳秒 - 注意：Java 8 的
LocalTime最高只保留纳秒精度，但构造时若传入超长小数位，会截断而非四舍五入 - 不要用
HH:mm:ss.nnn这种写法——n不是合法模式字母，必须用S
ISO_LOCAL_TIME 是最安全的内置格式器，但不支持偏移量
Java 提供了 DateTimeFormatter.ISO_LOCAL_TIME，它对应格式 HH:mm:ss 或 HH:mm:ss.SSS（自动适配 0–3 位毫秒），比硬编码模式更可靠。
- 推荐用于标准场景：
LocalTime.parse("14:25:10", DateTimeFormatter.ISO_LOCAL_TIME) - 它不接受带时区偏移的时间，如
"14:25:10+08:00"或"14:25:10Z"—— 这些属于OffsetTime范畴，应改用OffsetTime.parse - 若输入可能混有带偏移的字符串，先用正则或字符串截取剥离偏移部分，否则直接解析必报错
LocalTime.parse 在多线程下是安全的，但格式器实例最好复用
LocalTime.parse 本身是静态无状态方法，线程安全；但若每次调用都新建 DateTimeFormatter（尤其用 ofPattern 构造），会带来不必要的对象开销和潜在性能问题。
- 将常用格式器声明为
static final：private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("HH:mm:ss.SSSSSS"); - 避免在循环内反复创建格式器，尤其在高频日志时间解析等场景
-
DateTimeFormatter.ISO_LOCAL_TIME是单例，可直接复用，无需额外缓存
实际使用中最容易被忽略的是：你以为输入是“标准 ISO 时间”，结果它其实是完整 ISO 8601 时间戳（含日期和 T 分隔符），而你却坚持用 LocalTime.parse 去硬刚——这时候该换解析器，而不是调格式。
