localtime适用于纯时间场景，如闹钟、营业时间校验、课程表排期、物流承诺到达时段判断；它不带日期、不带时区、不参与日历计算，仅精确到纳秒。
LocalTime 适合哪些纯时间场景
闹钟、营业时间校验、课程表排期、物流承诺到达时段判断——这些都不需要知道是哪一天，只关心“几点几分几秒”。LocalTime 就是为这类场景设计的：它不带日期、不带时区、不参与日历计算，只精确到纳秒。
常见误用是拿 LocalDateTime 去存“14:30”，结果多出一个默认日期（比如 2026-04-13T14:30），后续做跨日比较或数据库映射时容易出错。真正该用 LocalTime 的地方，就别硬塞日期。
创建和解析 LocalTime 的坑点
LocalTime.of(14, 30) 安全；LocalTime.of(25, 0) 直接抛 DateTimeException；LocalTime.parse("14:30:00") 要求格式严格匹配，默认只认 HH:mm:ss，传 "2:30 PM" 或 "14:30" 都会失败。
- 想支持更宽松格式？得自己配
DateTimeFormatter：LocalTime.parse("14:30", DateTimeFormatter.ofPattern("HH:mm")) - 从秒数构造：用
LocalTime.ofSecondOfDay(54000)（即 15 小时 = 54000 秒），比手动拆小时分钟更可靠 - 注意
ofNanoOfDay的参数是纳秒总数（最大值约 86.4 亿），不是毫秒
时间比较和区间判断怎么写才稳
纯时间比较不能靠字符串或数字转换，必须用 compareTo 或 isBefore/isAfter。比如判断车辆是否“早于承诺时间到达”：
LocalTime actual = LocalTime.of(9, 45, 22); LocalTime promised = LocalTime.of(10, 0); int result = actual.compareTo(promised); // result <p>跨日场景（如夜班 22:00 到次日 6:00）要特别处理：</p>
- 如果起始时间 > 结束时间，说明是跨日区间，需分两段判断
- 不要用
isBefore直接比“当前时间是否在 22:00–06:00 内”，得写成：now.isAfter(start) || now.isBefore(end) - 数据库字段类型要匹配：PostgreSQL 用
TIME WITHOUT TIME ZONE，MySQL 用TIME，别误用DATETIME
LocalTime 为什么不能直接转时区时间
LocalTime 没有时区信息，所以不能直接调 withZoneSameInstant 或 atZone。想把它和具体时区绑定，必须先补上日期，变成 LocalDateTime，再用 atZone 升级为 ZonedDateTime：
LocalTime t = LocalTime.of(14, 30);
LocalDate d = LocalDate.now(); // 补日期（注意：这里用的是“今天”，不是任意日）
ZonedDateTime zdt = LocalDateTime.of(d, t).atZone(ZoneId.of("Asia/Shanghai"));
这个过程暴露了一个关键约束：你永远无法仅凭一个 LocalTime 知道它对应 UTC 的哪个瞬时点——缺日期，也缺时区，两者都不可逆推。业务上若需要跨时区调度，原始数据就不该只存 LocalTime。
