LocalTime专为纯时间场景设计，适用于闹钟、营业时间、课程表、排班系统、物流承诺到达时段等无需日期和时区的业务，具备不可变性与线程安全性。
LocalTime 适合哪些纯时间场景
闹钟、营业时间、课程表、排班系统、物流承诺到达时段——这些都不需要知道“哪一天”，只关心“几点几分几秒”。LocalTime 就是为这类场景设计的：它不存日期、不带时区、不可变，天然线程安全。如果你在做订单履约时间校验或定时任务调度，用 LocalTime 比硬塞 LocalDateTime 更干净，也比解析字符串更可靠。
创建和解析 LocalTime 的常见陷阱
LocalTime.of(25, 0) 会直接抛 DateTimeException，因为小时必须是 0–23；LocalTime.parse("14:30") 要求格式严格匹配默认模式 HH:mm，多一个空格或秒字段都会失败。实际开发中建议：
- 固定格式输入（如前端传
"HH:mm:ss"）时，用LocalTime.parse(str, formatter)显式指定DateTimeFormatter.ofPattern("HH:mm:ss") - 从秒/纳秒构造（比如从数据库整数字段还原），优先用
LocalTime.ofSecondOfDay(5400)（对应 01:30:00）或LocalTime.ofNanoOfDay(3600_000_000L)（对应 00:00:03.6） - 避免用
new Date().toInstant().atZone(ZoneId.systemDefault()).toLocalTime()这类绕路写法，直接调LocalTime.now()
比较和运算要注意边界条件
物流系统里常要判断“实际到达时间是否早于承诺时间”，这时用 actual.isBefore(promised) 比 actual.compareTo(promised) 更语义清晰。但注意：
-
LocalTime.MIN是00:00，LocalTime.MAX是23:59:59.999999999，不是24:00 - 加减操作如
time.plusHours(25)会自动取模（即 +25h ≡ +1h），这在跨日排班逻辑里容易出错，得先确认业务是否允许循环时间 - 没有“前一天”“后一天”的概念——
LocalTime不支持plusDays，强行用会编译失败
和数据库、JSON 交互时的序列化风险
JPA/Hibernate 默认把 LocalTime 映射为 TIME 类型，没问题；但 Spring Boot 的 Jackson 默认会把它序列化成 ISO 格式字符串（如 "14:30:00"），如果前端期望的是秒数或自定义格式，就得配 @JsonFormat(pattern = "HH:mm")。另外，MySQL 的 TIME 类型能存负值（表示时间差），而 LocalTime 不能——遇到时长计算场景，该换 Duration 就别硬扛。
