要计算两个时间点的秒数差，必须使用Instant等时间点类型而非Duration；推荐用Duration.between(start, end).toSeconds()获取四舍五入后的整秒数，注意LocalDateTime直接相减存在时区陷阱。
Duration 不能直接计算两个时间点的差值
Duration 本身是表示“时间段”的类型，不是时间点。它不存储起点或终点，只存时长（比如 3 小时 5 分钟 2 秒）。所以你不能拿两个 Duration 相减得到秒数——它们之间没有时间轴上的位置关系。
真正要算“两个时间点之间的秒数差”，必须先有可比较的时间点实例，比如 Instant、ZonedDateTime 或 LocalDateTime（注意后者无时区，慎用）。
用 Instant 和 Duration.between() 获取精确秒数差
最推荐的方式是：把两个时间点转成 Instant，再用 Duration.between() 得到 Duration 对象，最后调用 .getSeconds() 或 .toSeconds() 提取总秒数。
-
Duration.between()返回的是带纳秒精度的Duration，但.getSeconds()只返回整秒部分（丢弃纳秒），而.toSeconds()是四舍五入到最接近的整秒（Java 9+） - 如果需要亚秒级精度（比如毫秒或纳秒），直接用
.toMillis()或.toNanos() - 注意顺序：
Duration.between(start, end)，结果为正表示end在start之后
Instant start = Instant.parse("2024-05-01T10:00:00.123Z");
Instant end = Instant.parse("2024-05-01T10:00:05.456Z");
Duration d = Duration.between(start, end);
long seconds = d.toSeconds(); // → 5（四舍五入）
long nanos = d.toNanos(); // → 5_333_000_000
LocalDateTime 不带时区，直接相减会出错
很多人误以为 LocalDateTime 也能用 Duration.between()，语法上确实能跑，但结果依赖系统默认时区，且无法反映真实世界流逝时间（比如跨夏令时切换时，1 小时可能变成 61 分钟或 59 分钟）。
- 如果你硬要用
LocalDateTime，必须先显式转成ZonedDateTime或Instant，指定时区（如ZoneId.of("Asia/Shanghai")） - 直接对两个
LocalDateTime调用Duration.between()，底层会按系统默认时区解释成Instant，容易在部署环境变更时出偏差 - 错误示例：
Duration.between(ldt1, ldt2).toSeconds()—— 看似简洁，实则隐含时区陷阱
避免用 System.currentTimeMillis() 手动算秒数
有人图快，直接用 System.currentTimeMillis() 相减再除以 1000：
long diffSec = (endMs - startMs) / 1000;
这看似简单，但存在两个关键问题：
- 整数除法会直接截断小数部分（比如 1234ms → 1s），丢失精度；应改用
TimeUnit.MILLISECONDS.toSeconds()或保留 long 毫秒再换算 - 更严重的是：
System.currentTimeMillis()受系统时钟调整影响（NTP 同步、手动修改），可能导致差值突变甚至为负；而Instant基于单调时钟（如System.nanoTime()配合纪元偏移），更稳定
除非你在嵌入式或性能极端敏感场景且明确接受时钟漂移风险，否则别绕过 Instant。
真正要注意的其实是时间点的来源：数据库字段是 TIMESTAMP WITH TIME ZONE 还是 LOCALDATETIME？日志里的时间字符串有没有带时区？这些细节一旦错，后面所有 Duration 计算都是空中楼阁。
