Duration.between()返回Duration对象，需调用toMinutes()获取截断整数分钟，或用toNanos()除以60_000_000_000.0得精确小数分钟；推荐优先用Instant避免时区问题，大跨度场景可用ChronoUnit.MINUTES.between()防溢出。
Duration.between() 返回的是 Duration，不是直接的分钟数
Duration.between() 接收两个 Temporal（如 LocalDateTime、Instant），返回一个 Duration 对象，它内部以纳秒为单位存储时长。你不能直接把它当整数用，必须显式提取分钟数。
常见错误是写成：Duration.between(t1, t2).toMinutes() 看似合理，但要注意：如果两个时间点跨天或含秒/毫秒，toMinutes() 会向下取整（丢弃不足一分钟的部分），而有时你需要四舍五入或精确到小数分钟。
- 用
toMinutes()获取**整数分钟（截断）**，适合做粗略判断（比如“是否超过5分钟”） - 用
toNanos()再除以60_000_000_000L可得**精确小数分钟**（需转double） - 若输入是
LocalDateTime，确保它们在同一时区上下文里比较——Duration.between()本身不处理时区，只算时间轴上的差值
LocalDateTime 之间计算要小心“无时区”陷阱
LocalDateTime 没有时区信息，Duration.between() 只做纯数值差。比如 2024-03-10T01:30 到 2024-03-10T02:15 算出来是 45 分钟；但如果这天是夏令时开始日（如美国东部时间跳过 02:00），实际物理时间可能不是 45 分钟——Duration 不关心这个，它只按你给的字面值算。
- 业务上涉及真实流逝时间（如用户操作耗时、服务响应延迟），优先用
Instant而非LocalDateTime - 若必须用
LocalDateTime，确认输入已按需转换（例如统一转为系统默认时区的Instant后再算） - 别把
LocalDateTime和ZonedDateTime混着传给Duration.between()，会编译报错
正确示例：从 LocalDateTime 得到 double 类型分钟数
LocalDateTime start = LocalDateTime.of(2024, 3, 10, 14, 23, 30, 123_000_000); LocalDateTime end = LocalDateTime.of(2024, 3, 10, 14, 28, 45, 456_000_000); Duration d = Duration.between(start, end); long minutesTruncated = d.toMinutes(); // → 5 double minutesExact = (double) d.toNanos() / 60_000_000_000.0; // → 5.2555
注意 60_000_000_000.0 是 60 秒 × 10⁹ 纳秒/秒，写成带小数点的 double 字面量，避免整数除法截断。
toMinutes() 的溢出风险容易被忽略
Duration.toMinutes() 返回 long，但如果两个 LocalDateTime 相差极大（比如相隔几百年），Duration 内部纳秒值可能超出 long 表达范围，调用 toMinutes() 会抛 ArithmeticException。
- 生产环境处理用户输入的时间范围时，建议先用
Duration.abs().getSeconds()粗略检查是否过大（比如 >Long.MAX_VALUE / 60） - 更稳妥的做法是用
ChronoUnit.MINUTES.between()替代：它对LocalDateTime直接支持，且不会因纳秒溢出崩溃 -
ChronoUnit.MINUTES.between(t1, t2)返回的是long，但它是基于日期时间字段计算的，不依赖纳秒精度，适合大跨度场景
