1. 先搞清楚“昨日零点”到底要拿来做啥做 Java 后端的朋友应该都遇到过这种需求凌晨跑批要统计昨天一整天的订单量日报系统要拉取昨日零点到现在的流水对账程序要按天切分数据日志清理要删除昨天之前的所有记录。几乎所有按天统计的活儿都绕不开一个基础的时间边界——昨日零点。我最早写这个工具方法就是因为一个报表需求每天凌晨 2 点要把“昨天的订单”汇总出来。当时代码里直接写Calendar各种set、add、getTime满天飞一个月后换人维护差点把Calendar.MONTH从 0 开始的老账翻出来。后来改用java.time包整个工具类缩到几行测试也稳定了。这篇文章就把这套工具方法完整拆开讲包括实现思路、完整代码、定时任务和数据库查询怎么用以及几个我实际踩过的坑。内容适合刚学 Java 的同学也适合正在写报表、跑批任务的老手。1.1 从真实业务场景看需求要理解为什么需要“昨日零点”先看几个我实际做过的场景。第一个是每日经营报表。业务方要的是“昨天 00:00:00 到今天 00:00:00 之间创建的订单”而不是“最近 24 小时”。注意这两者不一样最近 24 小时会随着运行时间漂移昨天 10 点跑出来的“最近 24 小时”和今天 10 点跑出来的口径完全不同对账根本对不上。你可以把它理解成每天凌晨超市打烊后的盘点关键是先把“昨天”这一天的起止时间定死不然账根本对不齐。第二个是缓存过期与重置。比如每日榜单、每日库存快照需要在零点之后第一时间把昨天的数据归档、把今天的计数清零。这里的“零点”就是自然的业务分界散写在业务逻辑里的时间计算会随着代码越写越多变得越来越不可控。第三个是数据清理。日志表、临时表按天分区删除条件通常是create_time 昨日零点也就是把昨天零点之前的记录全部清理掉。这个查询条件如果写成create_time 昨天 23:59:59在毫秒、微秒精度下就会漏掉一批边缘数据。你会发现这些场景有一个共同点真正需要的不是某个“当前时刻”而是一个稳定的、可复现的时间边界。这个边界必须不受代码启动时间影响不受当天几点几分影响只取决于日期本身。这正是“昨日零点”这个工具方法存在的意义。1.2 为什么这个“一眼就会”的方法值得单独写一个工具类有人会说不就LocalDate.now().minusDays(1).atStartOfDay()一行代码吗有什么好封装的直接散写在业务代码里会带来几个问题。第一是口径不统一。张三在 Service A 里写的是“昨天零点”李四在 Service B 里实现的是“当天零点往前推 24 小时”王五用Calendar还忘了重置毫秒。三个地方跑出来的时间边界可能完全不一致出问题的时候查半天。第二是时区到处都是雷。LocalDate.now()使用的是 JVM 默认时区如果服务器部署在 UTC 时区而业务要求的是北京时间直接调用就会差 8 个小时。散写的代码很难统一修正。第三是不可测试。时间逻辑最怕依赖系统时钟写完工具类之后配合Clock注入可以很方便地固定时间做单元测试散写在业务里就没法这么干。第四是维护成本。以后要是统一调整时区策略、统一加日志埋点、统一兼容老接口只需要改一个工具类。这个收益会随着项目规模增长越来越明显尤其是有多个微服务共用一套基础包的时候。2. 核心实现基于 java.time 的工具方法2.1 一行代码拿到昨日零点LocalDateTime先来看最简单的版本public static LocalDateTime getYesterdayStart() { return LocalDate.now().minusDays(1).atStartOfDay(); }这行代码的语义非常清晰LocalDate.now()获取今天日期只包含年月日不包含时间minusDays(1)把日期回退一天自动处理跨月、跨年、闰年等边界atStartOfDay()把日期转换成当天 00:00:00 的LocalDateTime。我强烈建议使用atStartOfDay()而不是手动写LocalDateTime.of(LocalDate.now().minusDays(1), LocalTime.MIN)。虽然两者结果等价但atStartOfDay()语义更直接而且在某些带夏令时的时区里atStartOfDay()已经帮你处理了“当天 00:00 这个本地时间可能根本不存在”的特殊情况后面我会专门展开讲。返回类型选LocalDateTime而不是Date是这套工具的核心决策。LocalDateTime不携带时区表达的是一个“本地时间轴上的某个点”适合做业务分界Date内部本质是 UTC 时间戳的毫秒值打印和日志里经常被默认时区伪装成“带时区的时间”很容易造成误解。2.2 兼容老接口返回 Date 和 long 时间戳老项目里还有大量接口用Date数据库实体字段也可能是Date类型。所以我一般会在工具类里补两个重载版本。public static Date getYesterdayStartAsDate() { return Date.from(getYesterdayStart().atZone(ZoneId.systemDefault()).toInstant()); } public static long getYesterdayStartMillis() { return getYesterdayStart().atZone(ZoneId.systemDefault()).toInstant().toEpochMilli(); }这里的关键是atZone(ZoneId.systemDefault())。LocalDateTime本身没有时区概念必须把它放到某个时区的上下文中才能变成一个真正的时刻Instant再传给Date.from()。整个转换链路是LocalDateTime - ZonedDateTime挂上时区 - Instant绝对时间点 - Date毫秒包装一个常见的误区是直接Date.from(localDateTime.toInstant())编译会报错因为toInstant()是ZonedDateTime和Instant的方法LocalDateTime没有。很多新手卡在这一步其实就是没搞明白“本地时间”和“绝对时刻”的区别。提示LocalDateTime没有toInstant()必须先atZone(zone)变成ZonedDateTime再调用toInstant()这一步是新手最容易报错的地方。这里我建议在转换时始终显式传入ZoneId哪怕你觉得服务器就是默认时区。理由后面第 4 章会专门讲服务器时区被改、Docker 容器默认 UTC、CI 环境时区不一致这些我在真实项目里都遇到过。2.3 指定时区与可测试的 Clock 版本更稳妥的工具方法会把时区作为参数public static LocalDateTime getYesterdayStart(ZoneId zoneId) { return LocalDate.now(zoneId).minusDays(1).atStartOfDay(); }用的时候可以这样ZoneId bizZone ZoneId.of(Asia/Shanghai); LocalDateTime start YesterdayTimeUtils.getYesterdayStart(bizZone);为什么要显式传时区因为ZoneId.systemDefault()并不是一个可靠的常量。它读的是 JVM 启动参数user.timezone、操作系统时区、环境变量等多处配置任何一个环节变化都会影响结果。线上服务器很可能为了统一标准把时区设成 UTC而业务方要的其实是北京时间如果你依赖默认时区LocalDate.now()拿到的“今天”都不一定是业务意义上的“今天”。再往下走一步如果想让工具方法完全脱离系统时钟可以用Clockpublic static LocalDateTime getYesterdayStart(Clock clock) { return LocalDate.now(clock).minusDays(1).atStartOfDay(); }测试的时候传入固定时间Clock fixed Clock.fixed(Instant.parse(2025-06-15T10:00:00Z), ZoneId.of(Asia/Shanghai)); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(fixed);这样一来无论真实系统时间怎么变化测试结果都完全确定。这在做日报、对账这类强时间逻辑的测试时极为有用。2.4 曾经的主流方案Calendar 为什么该退休了既然很多人是从Calendar时代过来的我顺带把老代码贴出来对比一下public static Date getYesterdayStartByCalendar() { Calendar calendar Calendar.getInstance(); calendar.add(Calendar.DAY_OF_MONTH, -1); calendar.set(Calendar.HOUR_OF_DAY, 0); calendar.set(Calendar.MINUTE, 0); calendar.set(Calendar.SECOND, 0); calendar.set(Calendar.MILLISECOND, 0); return calendar.getTime(); }这段代码功能没问题但坑很多。Calendar.MONTH从 0 开始1 月是 02 月是 1写错一次就是整月错位DAY_OF_MONTH传 0 会被解释成上个月最后一天很多人第一次看到calendar.set(Calendar.DAY_OF_MONTH, 0)一脸懵Calendar是可变对象方法之间相互影响在复杂业务里容易被意外修改它也不是线程安全的放在多线程环境必须加锁或每次新建。java.time包从 Java 8 开始引入核心类全是不可变的方法名就是自然语言minusDays、atStartOfDay、plusDays读起来跟需求描述差不多。我接手过几个老项目凡是能用java.time重写的时间逻辑最后都改了改动量不大但排查时间问题的效率提升非常明显。3. 实操在 Spring Boot 项目里落地这套工具3.1 完整工具类代码为了方便直接“抄作业”我把实际项目里用到的完整工具类贴出来。package com.example.common.util; import java.time.Clock; import java.time.Instant; import java.time.LocalDate; import java.time.LocalDateTime; import java.time.ZoneId; import java.util.Date; /** * 按天边界计算工具类。 */ public final class YesterdayTimeUtils { private YesterdayTimeUtils() { throw new UnsupportedOperationException(工具类不允许实例化); } /** * 获取昨日零点使用 JVM 默认时区。 */ public static LocalDateTime getYesterdayStart() { return LocalDate.now().minusDays(1).atStartOfDay(); } /** * 获取昨日零点使用指定时区。 */ public static LocalDateTime getYesterdayStart(ZoneId zoneId) { return LocalDate.now(zoneId).minusDays(1).atStartOfDay(); } /** * 获取昨日零点使用外部传入时钟便于测试。 */ public static LocalDateTime getYesterdayStart(Clock clock) { return LocalDate.now(clock).minusDays(1).atStartOfDay(); } /** * 获取昨日零点的 Date 版本使用 JVM 默认时区。 */ public static Date getYesterdayStartAsDate() { return toDate(getYesterdayStart(), ZoneId.systemDefault()); } /** * 获取昨日零点的 Date 版本使用指定时区。 */ public static Date getYesterdayStartAsDate(ZoneId zoneId) { return toDate(getYesterdayStart(zoneId), zoneId); } /** * 获取昨日零点的时间戳毫秒使用 JVM 默认时区。 */ public static long getYesterdayStartMillis() { return toInstant(getYesterdayStart(), ZoneId.systemDefault()).toEpochMilli(); } /** * 获取昨日零点的时间戳毫秒使用指定时区。 */ public static long getYesterdayStartMillis(ZoneId zoneId) { return toInstant(getYesterdayStart(zoneId), zoneId).toEpochMilli(); } /** * 获取指定日期而不是今天的前一天零点。 */ public static LocalDateTime getPreviousDayStart(LocalDate date) { return date.minusDays(1).atStartOfDay(); } private static Instant toInstant(LocalDateTime localDateTime, ZoneId zoneId) { return localDateTime.atZone(zoneId).toInstant(); } private static Date toDate(LocalDateTime localDateTime, ZoneId zoneId) { return Date.from(toInstant(localDateTime, zoneId)); } }几点说明构造方法私有避免工具类被 new 出来getPreviousDayStart(LocalDate date)是为了处理“不是以今天为基准”的需求比如补数据、按指定日期重跑这个重载在运维场景里几乎一定会用到。3.2 在定时任务里配合 Scheduled 使用Spring Boot 项目里最常用的场景是定时任务。我一般这样写Component public class DailyReportTask { private final DailyReportService reportService; public DailyReportTask(DailyReportService reportService) { this.reportService reportService; } // 每天凌晨 30 分执行 Scheduled(cron 0 30 0 * * ?) public void generateYesterdayReport() { LocalDateTime start YesterdayTimeUtils.getYesterdayStart(); LocalDateTime end start.plusDays(1); reportService.generateReport(start, end); } }cron 表达式0 30 0 * * ?的意思是秒是 0分是 30时是 0也就是每天零点 30 分触发。为什么不定在 0 点整因为凌晨 0 点往往是数据库备份、缓存预热、跨天数据同步的高峰期任务排队、锁竞争都可能造成延迟。把时间定在 0 点 30 分牺牲 30 分钟换来的是更稳定的执行环境。我把start和end作为参数传给 Service而不是在 SQL 里再写一遍“昨天零点”的逻辑。这样 Service 和 Mapper 都不需要关心时间边界是怎么算出来的整个调用链只需要一次计算避免在不同层之间再次出现口径偏差。顺便说一句Scheduled默认是单线程执行的多个定时任务挤在同一个线程池里一个任务阻塞会拖累其他任务。如果项目里定时任务比较多建议自定义TaskScheduler的线程池大小这个跟本章主题关系不大但属于定时任务使用中容易忽略的细节。3.3 结合 MyBatis 查询“昨天产生了哪些数据”拿到昨日零点之后最典型的用法是查数据库。以订单表为例查询条件是“创建时间在昨日零点到今天零点之间”。Mapper 方法签名ListOrder selectByCreateTimeBetween(Param(start) LocalDateTime start, Param(end) LocalDateTime end);XML 里的写法select idselectByCreateTimeBetween resultTypecom.example.Order SELECT * FROM t_order WHERE create_time gt; #{start} AND create_time lt; #{end} /select这里特别注意一个细节我用的是 start AND end也就是数学上的左闭右开区间[start, end)而不是BETWEEN start AND end也不是 end。原因很简单BETWEEN在 MySQL 里是包含两端的也就是等价于 start AND end会把今天零点整这条记录也算进去。如果订单表里恰好在 00:00:00.000 生成了订单就会被重复统计。反过来如果写成 end并且end是“昨天 23:59:59.999”在 SQL Server、PostgreSQL 这类纳秒精度更高的数据库里仍然有漏掉边缘数据的风险。左闭右开区间是最干净的做法。统计时永远只包含“昨天一整天”今天零点整开始的数据自然落入下一个统计区间。另外如果数据库字段存的是DATETIMEMyBatis 配合 JDBC 4.2 驱动可以直接绑定LocalDateTime不需要手动转字符串。如果驱动版本太老可能出现Unsupported conversion之类的报错升级驱动即可解决。3.4 用单元测试把时间逻辑锁死时间逻辑最怕的是“今天跑没问题明天跑挂了”。所以工具类的测试我写得比较重。class YesterdayTimeUtilsTest { Test void shouldReturnYesterdayStartInDefaultZone() { LocalDateTime result YesterdayTimeUtils.getYesterdayStart(); LocalDate yesterday LocalDate.now().minusDays(1); assertEquals(yesterday.atStartOfDay(), result); } Test void shouldReturnYesterdayStartInGivenZone() { ZoneId zone ZoneId.of(Asia/Shanghai); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(zone); LocalDate yesterday LocalDate.now(zone).minusDays(1); assertEquals(yesterday.atStartOfDay(), result); } Test void shouldBeDeterministicWithFixedClock() { Clock fixed Clock.fixed( Instant.parse(2025-06-15T10:00:00Z), ZoneId.of(Asia/Shanghai)); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(fixed); assertEquals(LocalDate.parse(2025-06-14).atStartOfDay(), result); } Test void shouldZeroMillisecondsInDateVersion() { Date result YesterdayTimeUtils.getYesterdayStartAsDate(); assertEquals(0, result.getTime() % 1000); } Test void shouldHandleMonthBoundary() { LocalDate lastDayOfMay LocalDate.parse(2025-05-31); LocalDateTime result YesterdayTimeUtils.getPreviousDayStart(lastDayOfMay); assertEquals(LocalDate.parse(2025-05-30).atStartOfDay(), result); } }其中“固定时钟下结果完全确定”这个测试是最有价值的。它把系统时间彻底隔离无论测试跑在哪个时区、哪台机器、哪个时间点结果都是2025-06-14 00:00:00。这样 CI 上不会出现“昨天跑过、今天红了”的随机失败。4. 我踩过的坑时间工具的典型翻车现场4.1 时区不一致导致“零点”偏了8小时这是我职业生涯里最经典的一次事故。当时报表任务部署在 Kubernetes 集群里容器镜像默认时区是 UTC而业务方要的是北京时间。代码里写的是LocalDate.now()按 UTC 时区算出来的“昨天零点”比北京时间晚了 8 个小时。结果每天凌晨跑出来的报表数据整体少了一块而且不是恒定的——因为任务执行时刻不同UTC 和北京时间的日期切换点还经常不在同一个“业务日”里。排查的时候我做了三件事先在服务器上执行date看系统时区再在 Java 里打印ZoneId.systemDefault()和启动参数里的user.timezone最后检查数据库连接串里有没有serverTimezoneAsia/Shanghai。三处都对齐之后数据才正常。正确的做法是在工具方法里显式传入业务时区而不是依赖默认值。尤其是容器化部署镜像的/etc/localtime不一定继承了宿主机的配置最保险的方式是在 Dockerfile 里或者启动参数中显式设置时区同时在代码层用ZoneId.of(Asia/Shanghai)统一口径。4.2 闭开区间用错导致重复统计或漏数据这块我单独经历过两次翻车。第一次用了BETWEEN start AND end结果把今天零点整的订单也统计进了“昨天的报表”第二天发现数字比前一天多了 1 条。排查 SQL 最后定位到就是等号的问题。第二次用end start.plusDays(1).minusMillis(1)然后 end。当时数据库是 MySQL字段精度是毫秒问题不大。后来系统迁移到 PostgreSQLTIMESTAMP默认精度到微秒23:59:59.999会匹配到23:59:59.999123这条数据恰好漏掉了。从那以后我统一改成左闭右开区间SQL 里只写和再也不碰BETWEEN和“减 1 毫秒”这种土办法。强烈建议所有按天统计的时间范围统一写成 start AND end。这条规则只要坚持住能帮你避免一大半时间边界问题。4.3 SimpleDateFormat 线程安全翻车 vs DateTimeFormatter有一次线上偶发出一条日报数据异常日志里时间字段一会儿正一会儿负查了半天原因是工具类里用了静态的SimpleDateFormat。这个东西在多线程下会共享内部的Calendar状态导致parse()和format()结果错乱。后来统一换成DateTimeFormatter它是不可变、线程安全的可以直接定义为static final。这算是一个老生常谈的坑但我在团队里见过不止一次放在这篇时间工具相关的文章里再强调一遍。4.4 Java 8 以下项目怎么办如果你还在维护 Java 7 甚至是 Java 6 的项目java.time包确实用不了。历史方案是引入org.joda.time也就是 Joda-Time 库API 设计和现在的java.time非常像所以从 Joda-Time 迁移到java.time的成本很低。更省事的是用 ThreeTen Backport也就是java.time的向后移植版本包名是org.threeten.bp功能几乎完全一致Java 6、Java 7 都能跑。新项目建议直接上 Java 8 以上版本别再用Calendar和Date死磕了。4.5 夏令时与 atStartOfDay 的特殊情况国内没有夏令时很多人会忽略这一节。但做海外业务、跨境电商、国际物流的同学要特别注意。在部分实行夏令时的时区比如America/New_York春季某个凌晨 02:00 可能直接跳到 03:00也就是说当天不存在02:00:00这个本地时间秋季某个凌晨 01:00 可能重复出现两次。atStartOfDay()在实现上会参考时区规则返回“当天开始的实际时间”在跳变日可能会返回01:00:00或其他偏移值。如果用LocalDateTime.of(date, LocalTime.MIDNIGHT)手动构造零点再atZone(zone).toInstant()在跳变日就可能构造出根本不存在的本地时间。所以我一律推荐atStartOfDay()把时区规则的细节交给 JDK 处理。4.6 常见问题速查表问题现象解决思路结果比预期差8小时北京时间显示成UTC统一服务器时区代码显式传ZoneId.of(Asia/Shanghai)统计多了一条今天零点的数据数字比实际多改用[start, end)左闭右开区间统计少了一条边缘数据数字比实际少不要 end不要减1毫秒LocalDateTime转Date编译报错找不到toInstant()先atZone(zone)再toInstant()静态SimpleDateFormat偶发错乱多线程并发时时间串错换线程安全的DateTimeFormatterJava 7 项目编译失败找不到java.time包升级JDK或引入 ThreeTen BackportDocker容器时间不对日志时间全部是UTC镜像里显式设置时区代码层统一业务时区测试今天过、明天挂依赖真实系统时间工具方法支持Clock注入最后分享两个我自己用下来比较顺手的习惯。第一凡是跟时间边界相关的工具方法我通常直接返回LocalDateTime而不是Date因为Date在打印、比较、序列化时都容易暴露时区问题而LocalDateTime表达的就是“业务上的那个时间点”更不容易误解。第二所有定时任务的时间范围我都写成左闭右开区间并且把start、end作为参数传下去不在 SQL 里再写一遍NOW()之类的函数。这样即使哪天服务器时钟被 NTP 校准了一下报表逻辑也不会出现莫名其妙的偏差。时间这种东西你越较真线上越省心。 
长河君 · 2026/10/10 5:12:56 · 阅读 1.2k Java获取昨日零点：基于java.time的工具类实现与避坑指南
1. 先搞清楚“昨日零点”到底要拿来做啥做 Java 后端的朋友应该都遇到过这种需求凌晨跑批要统计昨天一整天的订单量日报系统要拉取昨日零点到现在的流水对账程序要按天切分数据日志清理要删除昨天之前的所有记录。几乎所有按天统计的活儿都绕不开一个基础的时间边界——昨日零点。我最早写这个工具方法就是因为一个报表需求每天凌晨 2 点要把“昨天的订单”汇总出来。当时代码里直接写Calendar各种set、add、getTime满天飞一个月后换人维护差点把Calendar.MONTH从 0 开始的老账翻出来。后来改用java.time包整个工具类缩到几行测试也稳定了。这篇文章就把这套工具方法完整拆开讲包括实现思路、完整代码、定时任务和数据库查询怎么用以及几个我实际踩过的坑。内容适合刚学 Java 的同学也适合正在写报表、跑批任务的老手。1.1 从真实业务场景看需求要理解为什么需要“昨日零点”先看几个我实际做过的场景。第一个是每日经营报表。业务方要的是“昨天 00:00:00 到今天 00:00:00 之间创建的订单”而不是“最近 24 小时”。注意这两者不一样最近 24 小时会随着运行时间漂移昨天 10 点跑出来的“最近 24 小时”和今天 10 点跑出来的口径完全不同对账根本对不上。你可以把它理解成每天凌晨超市打烊后的盘点关键是先把“昨天”这一天的起止时间定死不然账根本对不齐。第二个是缓存过期与重置。比如每日榜单、每日库存快照需要在零点之后第一时间把昨天的数据归档、把今天的计数清零。这里的“零点”就是自然的业务分界散写在业务逻辑里的时间计算会随着代码越写越多变得越来越不可控。第三个是数据清理。日志表、临时表按天分区删除条件通常是create_time 昨日零点也就是把昨天零点之前的记录全部清理掉。这个查询条件如果写成create_time 昨天 23:59:59在毫秒、微秒精度下就会漏掉一批边缘数据。你会发现这些场景有一个共同点真正需要的不是某个“当前时刻”而是一个稳定的、可复现的时间边界。这个边界必须不受代码启动时间影响不受当天几点几分影响只取决于日期本身。这正是“昨日零点”这个工具方法存在的意义。1.2 为什么这个“一眼就会”的方法值得单独写一个工具类有人会说不就LocalDate.now().minusDays(1).atStartOfDay()一行代码吗有什么好封装的直接散写在业务代码里会带来几个问题。第一是口径不统一。张三在 Service A 里写的是“昨天零点”李四在 Service B 里实现的是“当天零点往前推 24 小时”王五用Calendar还忘了重置毫秒。三个地方跑出来的时间边界可能完全不一致出问题的时候查半天。第二是时区到处都是雷。LocalDate.now()使用的是 JVM 默认时区如果服务器部署在 UTC 时区而业务要求的是北京时间直接调用就会差 8 个小时。散写的代码很难统一修正。第三是不可测试。时间逻辑最怕依赖系统时钟写完工具类之后配合Clock注入可以很方便地固定时间做单元测试散写在业务里就没法这么干。第四是维护成本。以后要是统一调整时区策略、统一加日志埋点、统一兼容老接口只需要改一个工具类。这个收益会随着项目规模增长越来越明显尤其是有多个微服务共用一套基础包的时候。2. 核心实现基于 java.time 的工具方法2.1 一行代码拿到昨日零点LocalDateTime先来看最简单的版本public static LocalDateTime getYesterdayStart() { return LocalDate.now().minusDays(1).atStartOfDay(); }这行代码的语义非常清晰LocalDate.now()获取今天日期只包含年月日不包含时间minusDays(1)把日期回退一天自动处理跨月、跨年、闰年等边界atStartOfDay()把日期转换成当天 00:00:00 的LocalDateTime。我强烈建议使用atStartOfDay()而不是手动写LocalDateTime.of(LocalDate.now().minusDays(1), LocalTime.MIN)。虽然两者结果等价但atStartOfDay()语义更直接而且在某些带夏令时的时区里atStartOfDay()已经帮你处理了“当天 00:00 这个本地时间可能根本不存在”的特殊情况后面我会专门展开讲。返回类型选LocalDateTime而不是Date是这套工具的核心决策。LocalDateTime不携带时区表达的是一个“本地时间轴上的某个点”适合做业务分界Date内部本质是 UTC 时间戳的毫秒值打印和日志里经常被默认时区伪装成“带时区的时间”很容易造成误解。2.2 兼容老接口返回 Date 和 long 时间戳老项目里还有大量接口用Date数据库实体字段也可能是Date类型。所以我一般会在工具类里补两个重载版本。public static Date getYesterdayStartAsDate() { return Date.from(getYesterdayStart().atZone(ZoneId.systemDefault()).toInstant()); } public static long getYesterdayStartMillis() { return getYesterdayStart().atZone(ZoneId.systemDefault()).toInstant().toEpochMilli(); }这里的关键是atZone(ZoneId.systemDefault())。LocalDateTime本身没有时区概念必须把它放到某个时区的上下文中才能变成一个真正的时刻Instant再传给Date.from()。整个转换链路是LocalDateTime - ZonedDateTime挂上时区 - Instant绝对时间点 - Date毫秒包装一个常见的误区是直接Date.from(localDateTime.toInstant())编译会报错因为toInstant()是ZonedDateTime和Instant的方法LocalDateTime没有。很多新手卡在这一步其实就是没搞明白“本地时间”和“绝对时刻”的区别。提示LocalDateTime没有toInstant()必须先atZone(zone)变成ZonedDateTime再调用toInstant()这一步是新手最容易报错的地方。这里我建议在转换时始终显式传入ZoneId哪怕你觉得服务器就是默认时区。理由后面第 4 章会专门讲服务器时区被改、Docker 容器默认 UTC、CI 环境时区不一致这些我在真实项目里都遇到过。2.3 指定时区与可测试的 Clock 版本更稳妥的工具方法会把时区作为参数public static LocalDateTime getYesterdayStart(ZoneId zoneId) { return LocalDate.now(zoneId).minusDays(1).atStartOfDay(); }用的时候可以这样ZoneId bizZone ZoneId.of(Asia/Shanghai); LocalDateTime start YesterdayTimeUtils.getYesterdayStart(bizZone);为什么要显式传时区因为ZoneId.systemDefault()并不是一个可靠的常量。它读的是 JVM 启动参数user.timezone、操作系统时区、环境变量等多处配置任何一个环节变化都会影响结果。线上服务器很可能为了统一标准把时区设成 UTC而业务方要的其实是北京时间如果你依赖默认时区LocalDate.now()拿到的“今天”都不一定是业务意义上的“今天”。再往下走一步如果想让工具方法完全脱离系统时钟可以用Clockpublic static LocalDateTime getYesterdayStart(Clock clock) { return LocalDate.now(clock).minusDays(1).atStartOfDay(); }测试的时候传入固定时间Clock fixed Clock.fixed(Instant.parse(2025-06-15T10:00:00Z), ZoneId.of(Asia/Shanghai)); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(fixed);这样一来无论真实系统时间怎么变化测试结果都完全确定。这在做日报、对账这类强时间逻辑的测试时极为有用。2.4 曾经的主流方案Calendar 为什么该退休了既然很多人是从Calendar时代过来的我顺带把老代码贴出来对比一下public static Date getYesterdayStartByCalendar() { Calendar calendar Calendar.getInstance(); calendar.add(Calendar.DAY_OF_MONTH, -1); calendar.set(Calendar.HOUR_OF_DAY, 0); calendar.set(Calendar.MINUTE, 0); calendar.set(Calendar.SECOND, 0); calendar.set(Calendar.MILLISECOND, 0); return calendar.getTime(); }这段代码功能没问题但坑很多。Calendar.MONTH从 0 开始1 月是 02 月是 1写错一次就是整月错位DAY_OF_MONTH传 0 会被解释成上个月最后一天很多人第一次看到calendar.set(Calendar.DAY_OF_MONTH, 0)一脸懵Calendar是可变对象方法之间相互影响在复杂业务里容易被意外修改它也不是线程安全的放在多线程环境必须加锁或每次新建。java.time包从 Java 8 开始引入核心类全是不可变的方法名就是自然语言minusDays、atStartOfDay、plusDays读起来跟需求描述差不多。我接手过几个老项目凡是能用java.time重写的时间逻辑最后都改了改动量不大但排查时间问题的效率提升非常明显。3. 实操在 Spring Boot 项目里落地这套工具3.1 完整工具类代码为了方便直接“抄作业”我把实际项目里用到的完整工具类贴出来。package com.example.common.util; import java.time.Clock; import java.time.Instant; import java.time.LocalDate; import java.time.LocalDateTime; import java.time.ZoneId; import java.util.Date; /** * 按天边界计算工具类。 */ public final class YesterdayTimeUtils { private YesterdayTimeUtils() { throw new UnsupportedOperationException(工具类不允许实例化); } /** * 获取昨日零点使用 JVM 默认时区。 */ public static LocalDateTime getYesterdayStart() { return LocalDate.now().minusDays(1).atStartOfDay(); } /** * 获取昨日零点使用指定时区。 */ public static LocalDateTime getYesterdayStart(ZoneId zoneId) { return LocalDate.now(zoneId).minusDays(1).atStartOfDay(); } /** * 获取昨日零点使用外部传入时钟便于测试。 */ public static LocalDateTime getYesterdayStart(Clock clock) { return LocalDate.now(clock).minusDays(1).atStartOfDay(); } /** * 获取昨日零点的 Date 版本使用 JVM 默认时区。 */ public static Date getYesterdayStartAsDate() { return toDate(getYesterdayStart(), ZoneId.systemDefault()); } /** * 获取昨日零点的 Date 版本使用指定时区。 */ public static Date getYesterdayStartAsDate(ZoneId zoneId) { return toDate(getYesterdayStart(zoneId), zoneId); } /** * 获取昨日零点的时间戳毫秒使用 JVM 默认时区。 */ public static long getYesterdayStartMillis() { return toInstant(getYesterdayStart(), ZoneId.systemDefault()).toEpochMilli(); } /** * 获取昨日零点的时间戳毫秒使用指定时区。 */ public static long getYesterdayStartMillis(ZoneId zoneId) { return toInstant(getYesterdayStart(zoneId), zoneId).toEpochMilli(); } /** * 获取指定日期而不是今天的前一天零点。 */ public static LocalDateTime getPreviousDayStart(LocalDate date) { return date.minusDays(1).atStartOfDay(); } private static Instant toInstant(LocalDateTime localDateTime, ZoneId zoneId) { return localDateTime.atZone(zoneId).toInstant(); } private static Date toDate(LocalDateTime localDateTime, ZoneId zoneId) { return Date.from(toInstant(localDateTime, zoneId)); } }几点说明构造方法私有避免工具类被 new 出来getPreviousDayStart(LocalDate date)是为了处理“不是以今天为基准”的需求比如补数据、按指定日期重跑这个重载在运维场景里几乎一定会用到。3.2 在定时任务里配合 Scheduled 使用Spring Boot 项目里最常用的场景是定时任务。我一般这样写Component public class DailyReportTask { private final DailyReportService reportService; public DailyReportTask(DailyReportService reportService) { this.reportService reportService; } // 每天凌晨 30 分执行 Scheduled(cron 0 30 0 * * ?) public void generateYesterdayReport() { LocalDateTime start YesterdayTimeUtils.getYesterdayStart(); LocalDateTime end start.plusDays(1); reportService.generateReport(start, end); } }cron 表达式0 30 0 * * ?的意思是秒是 0分是 30时是 0也就是每天零点 30 分触发。为什么不定在 0 点整因为凌晨 0 点往往是数据库备份、缓存预热、跨天数据同步的高峰期任务排队、锁竞争都可能造成延迟。把时间定在 0 点 30 分牺牲 30 分钟换来的是更稳定的执行环境。我把start和end作为参数传给 Service而不是在 SQL 里再写一遍“昨天零点”的逻辑。这样 Service 和 Mapper 都不需要关心时间边界是怎么算出来的整个调用链只需要一次计算避免在不同层之间再次出现口径偏差。顺便说一句Scheduled默认是单线程执行的多个定时任务挤在同一个线程池里一个任务阻塞会拖累其他任务。如果项目里定时任务比较多建议自定义TaskScheduler的线程池大小这个跟本章主题关系不大但属于定时任务使用中容易忽略的细节。3.3 结合 MyBatis 查询“昨天产生了哪些数据”拿到昨日零点之后最典型的用法是查数据库。以订单表为例查询条件是“创建时间在昨日零点到今天零点之间”。Mapper 方法签名ListOrder selectByCreateTimeBetween(Param(start) LocalDateTime start, Param(end) LocalDateTime end);XML 里的写法select idselectByCreateTimeBetween resultTypecom.example.Order SELECT * FROM t_order WHERE create_time gt; #{start} AND create_time lt; #{end} /select这里特别注意一个细节我用的是 start AND end也就是数学上的左闭右开区间[start, end)而不是BETWEEN start AND end也不是 end。原因很简单BETWEEN在 MySQL 里是包含两端的也就是等价于 start AND end会把今天零点整这条记录也算进去。如果订单表里恰好在 00:00:00.000 生成了订单就会被重复统计。反过来如果写成 end并且end是“昨天 23:59:59.999”在 SQL Server、PostgreSQL 这类纳秒精度更高的数据库里仍然有漏掉边缘数据的风险。左闭右开区间是最干净的做法。统计时永远只包含“昨天一整天”今天零点整开始的数据自然落入下一个统计区间。另外如果数据库字段存的是DATETIMEMyBatis 配合 JDBC 4.2 驱动可以直接绑定LocalDateTime不需要手动转字符串。如果驱动版本太老可能出现Unsupported conversion之类的报错升级驱动即可解决。3.4 用单元测试把时间逻辑锁死时间逻辑最怕的是“今天跑没问题明天跑挂了”。所以工具类的测试我写得比较重。class YesterdayTimeUtilsTest { Test void shouldReturnYesterdayStartInDefaultZone() { LocalDateTime result YesterdayTimeUtils.getYesterdayStart(); LocalDate yesterday LocalDate.now().minusDays(1); assertEquals(yesterday.atStartOfDay(), result); } Test void shouldReturnYesterdayStartInGivenZone() { ZoneId zone ZoneId.of(Asia/Shanghai); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(zone); LocalDate yesterday LocalDate.now(zone).minusDays(1); assertEquals(yesterday.atStartOfDay(), result); } Test void shouldBeDeterministicWithFixedClock() { Clock fixed Clock.fixed( Instant.parse(2025-06-15T10:00:00Z), ZoneId.of(Asia/Shanghai)); LocalDateTime result YesterdayTimeUtils.getYesterdayStart(fixed); assertEquals(LocalDate.parse(2025-06-14).atStartOfDay(), result); } Test void shouldZeroMillisecondsInDateVersion() { Date result YesterdayTimeUtils.getYesterdayStartAsDate(); assertEquals(0, result.getTime() % 1000); } Test void shouldHandleMonthBoundary() { LocalDate lastDayOfMay LocalDate.parse(2025-05-31); LocalDateTime result YesterdayTimeUtils.getPreviousDayStart(lastDayOfMay); assertEquals(LocalDate.parse(2025-05-30).atStartOfDay(), result); } }其中“固定时钟下结果完全确定”这个测试是最有价值的。它把系统时间彻底隔离无论测试跑在哪个时区、哪台机器、哪个时间点结果都是2025-06-14 00:00:00。这样 CI 上不会出现“昨天跑过、今天红了”的随机失败。4. 我踩过的坑时间工具的典型翻车现场4.1 时区不一致导致“零点”偏了8小时这是我职业生涯里最经典的一次事故。当时报表任务部署在 Kubernetes 集群里容器镜像默认时区是 UTC而业务方要的是北京时间。代码里写的是LocalDate.now()按 UTC 时区算出来的“昨天零点”比北京时间晚了 8 个小时。结果每天凌晨跑出来的报表数据整体少了一块而且不是恒定的——因为任务执行时刻不同UTC 和北京时间的日期切换点还经常不在同一个“业务日”里。排查的时候我做了三件事先在服务器上执行date看系统时区再在 Java 里打印ZoneId.systemDefault()和启动参数里的user.timezone最后检查数据库连接串里有没有serverTimezoneAsia/Shanghai。三处都对齐之后数据才正常。正确的做法是在工具方法里显式传入业务时区而不是依赖默认值。尤其是容器化部署镜像的/etc/localtime不一定继承了宿主机的配置最保险的方式是在 Dockerfile 里或者启动参数中显式设置时区同时在代码层用ZoneId.of(Asia/Shanghai)统一口径。4.2 闭开区间用错导致重复统计或漏数据这块我单独经历过两次翻车。第一次用了BETWEEN start AND end结果把今天零点整的订单也统计进了“昨天的报表”第二天发现数字比前一天多了 1 条。排查 SQL 最后定位到就是等号的问题。第二次用end start.plusDays(1).minusMillis(1)然后 end。当时数据库是 MySQL字段精度是毫秒问题不大。后来系统迁移到 PostgreSQLTIMESTAMP默认精度到微秒23:59:59.999会匹配到23:59:59.999123这条数据恰好漏掉了。从那以后我统一改成左闭右开区间SQL 里只写和再也不碰BETWEEN和“减 1 毫秒”这种土办法。强烈建议所有按天统计的时间范围统一写成 start AND end。这条规则只要坚持住能帮你避免一大半时间边界问题。4.3 SimpleDateFormat 线程安全翻车 vs DateTimeFormatter有一次线上偶发出一条日报数据异常日志里时间字段一会儿正一会儿负查了半天原因是工具类里用了静态的SimpleDateFormat。这个东西在多线程下会共享内部的Calendar状态导致parse()和format()结果错乱。后来统一换成DateTimeFormatter它是不可变、线程安全的可以直接定义为static final。这算是一个老生常谈的坑但我在团队里见过不止一次放在这篇时间工具相关的文章里再强调一遍。4.4 Java 8 以下项目怎么办如果你还在维护 Java 7 甚至是 Java 6 的项目java.time包确实用不了。历史方案是引入org.joda.time也就是 Joda-Time 库API 设计和现在的java.time非常像所以从 Joda-Time 迁移到java.time的成本很低。更省事的是用 ThreeTen Backport也就是java.time的向后移植版本包名是org.threeten.bp功能几乎完全一致Java 6、Java 7 都能跑。新项目建议直接上 Java 8 以上版本别再用Calendar和Date死磕了。4.5 夏令时与 atStartOfDay 的特殊情况国内没有夏令时很多人会忽略这一节。但做海外业务、跨境电商、国际物流的同学要特别注意。在部分实行夏令时的时区比如America/New_York春季某个凌晨 02:00 可能直接跳到 03:00也就是说当天不存在02:00:00这个本地时间秋季某个凌晨 01:00 可能重复出现两次。atStartOfDay()在实现上会参考时区规则返回“当天开始的实际时间”在跳变日可能会返回01:00:00或其他偏移值。如果用LocalDateTime.of(date, LocalTime.MIDNIGHT)手动构造零点再atZone(zone).toInstant()在跳变日就可能构造出根本不存在的本地时间。所以我一律推荐atStartOfDay()把时区规则的细节交给 JDK 处理。4.6 常见问题速查表问题现象解决思路结果比预期差8小时北京时间显示成UTC统一服务器时区代码显式传ZoneId.of(Asia/Shanghai)统计多了一条今天零点的数据数字比实际多改用[start, end)左闭右开区间统计少了一条边缘数据数字比实际少不要 end不要减1毫秒LocalDateTime转Date编译报错找不到toInstant()先atZone(zone)再toInstant()静态SimpleDateFormat偶发错乱多线程并发时时间串错换线程安全的DateTimeFormatterJava 7 项目编译失败找不到java.time包升级JDK或引入 ThreeTen BackportDocker容器时间不对日志时间全部是UTC镜像里显式设置时区代码层统一业务时区测试今天过、明天挂依赖真实系统时间工具方法支持Clock注入最后分享两个我自己用下来比较顺手的习惯。第一凡是跟时间边界相关的工具方法我通常直接返回LocalDateTime而不是Date因为Date在打印、比较、序列化时都容易暴露时区问题而LocalDateTime表达的就是“业务上的那个时间点”更不容易误解。第二所有定时任务的时间范围我都写成左闭右开区间并且把start、end作为参数传下去不在 SQL 里再写一遍NOW()之类的函数。这样即使哪天服务器时钟被 NTP 校准了一下报表逻辑也不会出现莫名其妙的偏差。时间这种东西你越较真线上越省心。