LocalTime.isAfter只能比较LocalTime类型，需统一类型；跨午夜需结合isBefore判断；时区不一致会导致误判，应显式指定ZoneId。
LocalTime.isAfter 为什么不能直接和系统当前时间比较
LocalTime.isAfter 接收的是另一个 LocalTime 对象，不是 Instant 或 ZonedDateTime。如果你直接传 LocalDateTime.now() 或 System.currentTimeMillis()，编译就报错——类型不匹配。
常见错误写法：LocalTime.now().isAfter(LocalDateTime.now())，会提示 “no instance of method isAfter(LocalDateTime)”。
关键点：必须统一为 LocalTime 类型才能调用 isAfter。
怎么提取并比较营业结束时间
假设营业时间是 9:00–18:30，你想判断“现在是否已过 18:30”。需要把当前时刻的时分秒截出来，再和营业结束时间比：
- 用
LocalTime.now()获取当前本地时分秒（不带日期、不带时区） - 用
LocalTime.of(18, 30)构造营业结束时间（注意不要用字符串解析，避免异常） - 调用
LocalTime.now().isAfter(endTime)得到布尔结果
示例：
LocalTime now = LocalTime.now(); LocalTime endTime = LocalTime.of(18, 30); boolean isClosed = now.isAfter(endTime); // true 表示已超时
营业时间跨午夜（比如凌晨 2 点关门）怎么处理
如果营业时间是 22:00 到次日 2:00，isAfter 单独用就不够了——因为 LocalTime.of(2, 0) 比 LocalTime.now()（比如 23:00）小，isAfter 会返回 false，逻辑就反了。
这时不能只看“是否晚于结束时间”，得结合“是否早于开始时间”做区间判断：
- 定义
startTime = LocalTime.of(22, 0)，endTime = LocalTime.of(2, 0) - 若
now.isAfter(startTime) || now.isBefore(endTime)，说明在营业中（跨天场景） - 反之才是已关门
注意：这种逻辑下 isAfter 只是其中一环，不能单独扛全部判断。
时区偏差导致判断出错的隐性坑
LocalTime.now() 默认用系统默认时区的“本地时间”，但如果你的服务部署在 UTC 服务器，而业务面向东八区用户，LocalTime.now() 返回的就是 UTC 时间（比如 10:00），和你按北京时间写的 LocalTime.of(18, 30) 对不上。
解决办法只有两个：
- 显式指定时区：用
LocalTime.now(ZoneId.of("Asia/Shanghai")) - 或者统一用
ZonedDateTime处理，再提取toLocalTime()（但要注意时区转换后的时间值是否符合预期）
没指定时区是最容易被忽略的点，测试时本地跑得通，上线后时间全乱。
