Duration.between返回Duration对象，以纳秒存储但需显式调用toMillis()获取毫秒值；应统一用Instant.now()而非混用System.currentTimeMillis()；LocalDateTime不可直接使用，须转为Instant；高频场景优先考虑System.nanoTime()。
Duration.between 返回的是时间跨度，不是毫秒数
Duration.between 返回的是 Duration 对象，它内部以纳秒为单位存储时长，但不会自动转成毫秒。直接打印或比较时容易误以为是毫秒值，比如 PT0.123S 看起来像 123 毫秒，其实是 0.123 秒（即 123 毫秒），但这个字符串格式不可用于计算——必须显式提取数值。
常见错误是写成：Duration.between(start, end).toString() 然后试图解析字符串，这既慢又易错。
- 正确做法：调用
.toMillis()获取四舍五入后的毫秒值（long类型） - 若需更高精度，用
.toNanos()再除以 1_000_000.0 得到带小数的毫秒（注意溢出风险） -
.toMillis()会丢弃不足 1 毫秒的纳秒部分（向下取整？不，是四舍五入到最接近的毫秒）
Instant 必须来自同一时钟源，否则结果不可靠
用 System.currentTimeMillis() 转成 Instant 是常见错误源头。例如：Instant.ofEpochMilli(System.currentTimeMillis()) 看似可行，但 System.currentTimeMillis() 可能被系统时钟调整影响（NTP 同步、手动改时间），导致 Duration.between 算出负值或异常大值。
真实任务计时应统一用 Instant.now()，它基于 Java 的默认时钟（通常绑定 System.nanoTime() 做单调性保障）。
- ✅ 推荐：起始和结束都用
Instant.now() - ❌ 避免混用：
Instant.ofEpochMilli(...)和Instant.now() - ⚠️ 注意：跨进程或分布式场景下，
Instant.now()无法保证一致性，此时不该用Duration.between做精确对比
别忽略时区与日期类混淆——LocalDateTime 不适用
有人误把 LocalDateTime 当作时间点传给 Duration.between，编译直接报错，因为该方法只接受两个 Temporal 且必须能转换为时间线上的绝对点（Instant 或等价物）。LocalDateTime 没有时区信息，无法定位到时间轴。
典型错误代码：Duration.between(LocalDateTime.now(), LocalDateTime.now().plusSeconds(1)) → 编译失败。
- ✅ 正确输入类型：两个
Instant、或一个Instant和一个ZonedDateTime - ✅ 若只有日期时间对象，先转成带时区的：
localDateTime.atZone(ZoneId.systemDefault()).toInstant() - ⚠️
OffsetDateTime可以直接用，但要注意偏移量是否一致；不一致时仍会算出合理差值，但语义可能偏离预期
性能敏感场景下，避免频繁创建 Instant 对象
在高频任务（如每毫秒执行一次的小循环）中反复调用 Instant.now()，开销比 System.nanoTime() 高不少——前者涉及时区处理和对象分配，后者只是读寄存器。
如果只要毫秒差，且不需要挂载到 UTC 时间线，优先考虑更轻量的方式：
- 纯毫秒差：用
System.currentTimeMillis()相减（注意时钟跳跃风险） - 高精度+单调性：用
System.nanoTime()，再除以 1_000_000L 得毫秒（仍是long，无小数） - 只有当你需要把耗时和日志中的
Instant关联、或做跨服务时间对齐时，才值得用Duration.between
真正需要 Duration.between 的地方，往往不是“测单次执行”，而是“记录某次请求从收到 Instant 到返回 Instant 的跨度”，这时对象创建成本已远低于网络或业务逻辑本身。
