TimeUnit.convert返回0或结果错误本质是整数截断：底层用Math.floorDiv或整除丢弃小数，如999毫秒转秒得0；需按需选用Duration保留精度或手动换算。
TimeUnit.convert 为什么返回 0 或结果不对
本质是整数截断问题：TimeUnit.convert 底层调用 Math.floorDiv（Java 8+）或等效整除逻辑，直接丢弃小数部分。比如把 999 毫秒转成秒，TimeUnit.SECONDS.convert(999, TimeUnit.MILLISECONDS) 返回 0，不是四舍五入，也不是报错，就是纯整除。
常见错误现象：
- 传入值小于目标单位的最小整数倍（如毫秒转秒时传
499），结果恒为0 - 误以为它能处理浮点精度，实际所有参数和返回值都是
long - 在需要“向上取整”或“四舍五入”的场景硬套它，导致业务逻辑偏差
正确做法：先确认是否真需要整数结果。如果要保留精度，改用 TimeUnit.toNanos + 手动换算，或转成 Duration 再调 toSecondsPart/toMillisPart 等方法。
TimeUnit.convert 和 Duration 的选择边界
TimeUnit.convert 是轻量、无状态、纯静态工具；Duration 是面向对象的时间量模型，自带精度保留和复合运算能力。选哪个，取决于你是否需要“时间量”语义。
立即学习“Java免费学习笔记（深入）”；
使用场景对比：
- 做配置解析、日志采样间隔转换（如
"30s"→ 毫秒数）→ 用TimeUnit.convert更直接 - 计算两个时间点差值后做分段统计（如“超过 5 分钟但不足 10 分钟的请求”）→ 用
Duration更安全，避免多次convert累积误差 - 涉及纳秒级精度或负时间量 →
TimeUnit.convert不支持纳秒作为源单位（只有NANOSECONDS可作目标单位），必须用Duration
性能提示：单次转换两者差异可忽略；高频循环中反复构造 Duration 对象会有 GC 压力，此时坚持用 TimeUnit 静态方法更稳。
跨单位转换时单位顺序写反的典型错误
TimeUnit.convert 参数顺序固定：convert(long sourceDuration, TimeUnit sourceUnit)。最容易翻车的是把单位搞反，比如想把 2 小时转成毫秒，却写成 TimeUnit.MILLISECONDS.convert(2, TimeUnit.HOURS) —— 这其实是“把 2 毫秒按小时单位解释再转成毫秒”，结果是 2，不是 7200000。
记住口诀：第一个参数是你手上的原始数字，第二个参数是它“本来是什么单位”。反过来就等于让系统误读数值含义。
容易踩的坑：
- 复制粘贴其他代码时没改单位参数，尤其从
MINUTES改成HOURS时漏掉同步改第二个参数 - IDE 自动补全可能默认塞进
TimeUnit.MILLISECONDS，你没注意就点了回车 - 单元测试只覆盖了“大数转小单位”，没测“小数转大单位”，掩盖了参数颠倒问题
Java 8 与 Java 9+ 在 TimeUnit.convert 上的兼容性细节
Java 9 引入了 TimeUnit.convert 的重载版本，支持 ChronoUnit，但日常开发几乎用不到。真正影响行为的是底层整除实现变化：Java 8 用 (x / y)，Java 9+ 改用 Math.floorDiv(x, y)，对正数没区别，但对负数结果一致（都向零截断），所以不用刻意规避版本差异。
不过要注意一个隐藏限制：TimeUnit 不支持自定义单位，也不能扩展。如果你需要转换“工作日”“CPU 周期”这类非标准单位，别试图绕过它封装——直接写独立工具类，否则后期维护成本远高于收益。
复杂点在于：它不报错、不告警、不提示溢出。比如用 TimeUnit.DAYS.convert(Long.MAX_VALUE, TimeUnit.NANOSECONDS)，结果是 106751991（看似合理），但真实天数其实是约 292 年，而 Long.MAX_VALUE 纳秒 ≈ 292 年，这里没溢出；但若换成 TimeUnit.SECONDS.convert(Long.MAX_VALUE, TimeUnit.NANOSECONDS)，结果会因整除截断丢失精度，且完全无法感知。
