Java 8 的 java.time API 不可变且线程安全，单元测试应通过 Clock 注入隔离系统时钟，显式指定 ZoneId 避免依赖默认时区，并覆盖跨日/时区转换/解析异常等边界场景。
Java 8 引入的 java.time API（如 LocalDateTime、ZonedDateTime、Clock）本身是不可变且线程安全的，单元测试时关键在于**隔离系统时钟依赖、控制时间上下文、验证时区/格式/计算逻辑**。不推荐直接用 new Date() 或 System.currentTimeMillis()，而应通过依赖注入或参数化方式让时间可被模拟。
用 Clock 控制时间源头
Clock 是 java.time 中抽象系统时钟的核心接口，所有静态工厂方法（如 LocalDateTime.now(Clock)）都支持传入自定义 Clock。这是最推荐的解耦方式：
- 将
Clock作为构造参数或方法参数注入到被测类中，避免硬编码LocalDateTime.now() - 测试中使用
Clock.fixed(Instant, ZoneId)模拟固定时刻，或Clock.offset(baseClock, Duration)模拟偏移 - 例如：
Clock fixedClock = Clock.fixed(Instant.parse("2024-05-20T10:00:00Z"), ZoneId.of("UTC"));，后续调用LocalDateTime.now(fixedClock)总返回同一值
避免直接依赖系统时间的方法
如果代码已存在 LocalDateTime.now() 等无参调用，重构优先级高于打桩。若短期无法修改，可用以下方式临时应对：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 使用
Mockito的mockStatic（需 Mockito 3.4.0+，且仅限 Java 14+）mockLocalDateTime静态方法（不推荐长期使用，破坏函数式设计） - 封装一层工具类（如
TimeProvider.now()），在测试中替换其实现，比直接 mock JDK 类更可控 - 对
System.currentTimeMillis()打桩（如 PowerMock）风险高、兼容性差，应避免
验证日期计算与格式化行为
重点覆盖边界场景和易错点：
- 跨日/跨月/跨年计算：如
LocalDate.plusDays(30)在 1 月 31 日是否正确落到 3 月 2 日（考虑各月天数） - 时区转换：用
ZonedDateTime.withZoneSameInstant()或withZoneSameLocal()后，验证偏移量、夏令时是否符合预期 - 解析与格式化：用
DateTimeFormatter解析字符串时，检查模式是否严格（如yyyy-MM-dd不接受2024/05/20），并测试异常路径（如解析非法格式抛出DateTimeParseException）
测试时区敏感逻辑要显式指定 ZoneId
不要依赖 ZoneId.systemDefault()，因为测试环境时区可能变化：
- 所有涉及时区的操作（如
ZonedDateTime.now(zoneId)、Instant.atZone(zoneId)）都应传入明确的ZoneId，如ZoneId.of("Asia/Shanghai") - 测试中固定时区，避免因 CI 服务器或开发者本地时区不同导致结果漂移
- 若业务逻辑必须适配系统时区，可在测试前用
TimeZone.setDefault()临时设置（注意恢复，建议用@BeforeEach/@AfterEach或 JUnit 5 的TestInstance.Lifecycle.PER_METHOD隔离）
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
