Java中before()和after()用于日期比较，但对象不能为null，否则抛NullPointerException；Date、Calendar支持，LocalDateTime需转Instant；推荐先判空再调用，语义比compareTo()更直白。
Java里用before()和after()比较日期，前提是对象不能为null
这两个方法是Date、Calendar甚至LocalDateTime（需转成Instant）都支持的常用判断逻辑，但最常踩的坑是直接对null调用——会立刻抛NullPointerException。尤其从数据库或API取时间字段时，空值很常见。
实操建议：
- 调用前先用
Objects.nonNull()或!= null判空，别依赖文档说“一般不为空” - 如果用的是
LocalDateTime，它本身没有before()，得先转成Instant：time1.atZone(ZoneId.systemDefault()).toInstant().isBefore(time2.atZone(...).toInstant()) -
Date.before()底层比的是毫秒值，所以只要两个Date对象都非null，结果就是确定的，不受时区影响
为什么不用compareTo()而选before()/after()
因为语义更直白，可读性更强。比如if (date1.before(date2))比if (date1.compareTo(date2) 少一层心智转换，也避免写错符号（<code>> 0还是）。
但要注意：
立即学习“Java免费学习笔记（深入）”；
-
compareTo()返回-1/0/1，能同时判断相等；before()和after()只管大小，相等时全返回false - 如果业务需要“小于等于”，别写
!date1.after(date2)——虽然逻辑对，但可读性差，容易被后续维护者误改 - 在集合排序（如
TreeSet）中必须用compareTo()，before()无法替代
before()在Java 8+时间API里怎么对应
Java 8之后官方推荐用java.time包，但老代码里还大量存在Date，新项目又倾向用LocalDateTime或ZonedDateTime。它们之间不是简单一对一替换。
关键差异：
-
LocalDateTime没有before()，因为它不带时区，无法直接比较“真实时间先后”——比如2024-01-01T12:00在北京和纽约不是同一时刻 - 真要比较，得升格为
ZonedDateTime或转成Instant：time1.atZone(ZoneId.of("Asia/Shanghai")).isBefore(time2.atZone(ZoneId.of("UTC"))) - 如果只是业务上“同一天内按字符串顺序排”，那用
toString()再compareTo()也行，但得加注释说明这是业务约定，不是时间语义
测试时容易漏掉的边界情况
光测2023-01-01和2023-01-02不够。真实系统里这些场景更易出错：
- 同一天、同一秒、不同毫秒：
new Date(1700000000000L)vsnew Date(1700000000001L)——before()必须返回true - 夏令时切换当天：比如美国东部时间3月10日2:00跳到3:00，中间那小时不存在，
ZonedDateTime会自动调整，但LocalDateTime不会报错，比较结果可能反直觉 - 跨年份的
LocalDate比较：它有isBefore()，但名字和Date.before()不一致，容易在重构时漏改
时间比较真正麻烦的从来不是语法，而是你默认的那个“当前时区”“是否考虑夏令时”“毫秒精度是否重要”，这些没写进代码里，只存在于你脑子里。
