LocalTime 处理纯时间逻辑的实用方法

LocalTime 是专为处理纯时间（“几点几分”）场景设计的不可变类型，但其严格性与特殊性常被开发者忽视：解析时需显式指定格式避免 DateTimeException，跨日区间判断必须先检测 start.isAfter(end) 再分段逻辑，数据库映射须确保字段为 TIME 类型并避开 DATETIME 陷阱，JSON 序列化需用 @JsonFormat 精确控制输出格式，而它天生不含时区、不能直接升格——任何混用 LocalDateTime、字符串拼接或绕路转换的操作，都会在跨日比较、持久化和前后端交互中悄然埋雷。

直接用 LocalTime，别碰 LocalDateTime 或字符串拼接——它就是专为“几点几分”这类场景设计的，强行加日期或转字符串，后续跨日比较、数据库映射、JSON 序列化全会出问题。

创建和解析时为什么总抛 DateTimeException

LocalTime 对输入极其严格：小时必须是 0–23，分钟/秒必须是 0–59，且默认 parse() 只认 "HH:mm:ss" 格式。传 "14:30" 或 "2:30 PM" 都会直接炸。

• 固定格式（如前端传 "HH:mm:ss"）：显式配 DateTimeFormatter.ofPattern("HH:mm:ss")，别依赖默认
• 需要支持 "HH:mm"：用 LocalTime.parse("14:30", DateTimeFormatter.ofPattern("HH:mm"))
• 从整数字段还原（比如数据库存的是秒数 54000）：优先用 LocalTime.ofSecondOfDay(54000)，比手动拆小时分钟更安全
• 避免绕路写法：别用 new Date().toInstant().atZone(...).toLocalTime()，直接 LocalTime.now()

跨日区间判断（比如夜班 22:00 到次日 6:00）怎么写才不翻车

纯时间没有“昨天”“明天”概念，isBefore/isAfter 在跨日区间里直接失效。比如 now.isAfter(start) && now.isBefore(end) 在 start=22:00、end=06:00 时永远返回 false。

• 先判断是否跨日：if (start.isAfter(end))
• 再分两段写：now.isAfter(start) || now.isBefore(end)
• 别用 compareTo 做区间判断——语义不清，容易漏边界
• 注意 LocalTime.MIN 是 00:00，LocalTime.MAX 是 23:59:59.999999999，不是 24:00

和数据库、JSON 打交道时哪些配置不能少

JPA/Hibernate 默认把 LocalTime 映射成 TIME WITHOUT TIME ZONE（PostgreSQL）或 TIME（MySQL），看着没问题，但实际常踩两个坑：

• Spring Boot 的 Jackson 默认序列化成 ISO 字符串（如 "14:30:00"），如果前端要 "HH:mm" 或秒数，必须加 @JsonFormat(pattern = "HH:mm")
• MySQL 的 TIME 类型能存负值（表示时间差），而 LocalTime 不能——遇到时长计算（如“提前了 15 分钟”），该换 Duration 就别硬扛
• 数据库字段类型必须匹配：千万别用 DATETIME 或 TIMESTAMP 存 LocalTime，否则多出的日期部分全是默认值，后续查出来是 "1970-01-01T14:30:00" 这种假数据

最易被忽略的一点：LocalTime 不能直接升格为带时区的时间。它没有时区信息，所以 .atZone() 会编译失败；想绑定时区，必须先补一个 LocalDate，再组合成 LocalDateTime，最后调 atZone() —— 这个“补日期”的动作本身就有业务含义，用 LocalDate.now() 不代表“任意一天”，而是“今天”。

今天关于《LocalTime 处理纯时间逻辑的实用方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！