timeunit.tomillis() 是枚举实例方法，只能通过 timeunit.xxx 调用，不支持字符串或自定义单位；需手动解析配置中的“30s”等格式并映射到对应枚举；与 duration.tomillis() 语义不同，前者纯数学换算，后者基于纳秒精度且适合组合逻辑。
TimeUnit.toMillis() 为什么不能直接传入字符串或自定义单位
TimeUnit.toMillis() 是个实例方法，必须通过具体的枚举值调用，比如 TimeUnit.SECONDS.toMillis(5)，而不是 TimeUnit.toMillis(5, "SECONDS")。Java 没有提供运行时解析时间单位字符串的重载版本，硬写字符串会编译失败或触发 NoSuchMethodError。
常见错误是误以为它像 Duration.parse() 那样支持灵活输入，结果在单元测试里传了 "MINUTES" 字符串，直接报 NullPointerException（因为枚举值为 null）。
- 只能用
TimeUnit.NANOSECONDS、TimeUnit.MICROSECONDS、TimeUnit.MILLISECONDS、TimeUnit.SECONDS、TimeUnit.MINUTES、TimeUnit.HOURS、TimeUnit.DAYS这七个枚举常量 - 传入负数会返回负的毫秒值，不会抛异常，但业务逻辑可能出错（比如超时配置为 -1 分钟）
- 注意整数溢出：例如
TimeUnit.DAYS.toMillis(Long.MAX_VALUE)会溢出成负数，建议对大数值做预检查或改用Duration
如何安全地把配置里的“30s”、“2m”转成毫秒
配置项（如 YAML/properties）里的时间通常带单位后缀，TimeUnit.toMillis() 不处理这种格式，得自己拆解。推荐用正则提取数字和单位，再映射到对应 TimeUnit 枚举：
String raw = "30s";
Matcher m = Pattern.compile("(\d+)([smhd])").matcher(raw);
if (m.find()) {
long value = Long.parseLong(m.group(1));
TimeUnit unit = switch (m.group(2)) {
case "s" -> TimeUnit.SECONDS;
case "m" -> TimeUnit.MINUTES;
case "h" -> TimeUnit.HOURS;
case "d" -> TimeUnit.DAYS;
default -> throw new IllegalArgumentException("Unknown unit: " + m.group(2));
};
long millis = unit.toMillis(value); // 得到 30_000
}
注意点：
- 别用
Integer.parseInt()，配置可能超过Integer.MAX_VALUE（比如 “1000000h”） - 小写单位更稳妥，避免大小写判断；如果配置含大写，统一
.toLowerCase() - 不建议用
TimeUnit.valueOf(name.toUpperCase()).toMillis(value)——valueOf()对"S"抛IllegalArgumentException（枚举名是SECONDS）
TimeUnit.toMillis() 和 Duration.toMillis() 的关键区别
两者都返回 long 毫秒值，但语义和边界行为不同：TimeUnit.toMillis() 是纯数学换算，而 Duration.toMillis() 是基于纳秒精度的时长对象，会截断小数部分且对纳秒级精度更敏感。
-
TimeUnit.SECONDS.toMillis(1)→1000（精确） -
Duration.ofSeconds(1).toMillis()→1000（一样） -
TimeUnit.MILLISECONDS.toMillis(999)→999（原样返回） -
Duration.ofMillis(999).toMillis()→999（也一样） - 但
Duration.ofNanos(1_500_000).toMillis()→1（向下取整），而TimeUnit.NANOSECONDS.toMillis(1_500_000)→1（同样截断）
真正差异在构造阶段：Duration 支持 ofDays()、ofHours() 等链式构建，适合组合逻辑；TimeUnit 更轻量，适合单次换算。别混用：比如用 TimeUnit.SECONDS.toMillis(duration.getSeconds()) 会丢失纳秒部分。
在并发或定时任务中用 toMillis() 要防什么
像 ScheduledExecutorService.schedule(Runnable, delay, unit) 内部其实就调用了 unit.toMillis(delay)，所以你传 TimeUnit.MINUTES 和 5，它内部算出 300_000。问题在于：这个值是 long 类型，但某些老版本 JDK 的定时器实现对超大延迟（如几百年）处理不一致。
- OpenJDK 8u202+ 对
Long.MAX_VALUE毫秒以上延迟会静默截断，导致任务立即执行 - 若 delay 来自用户输入（如管理后台填“超时：1000000000 秒”），务必校验上限，比如限制最大为
TimeUnit.DAYS.toMillis(3650)（10 年） - 不要在循环里反复调用
TimeUnit.XXX.toMillis(constant)—— 提前算好存为常量，避免重复计算（虽然开销极小，但可读性差）
最易被忽略的是时区无关性：所有 TimeUnit 换算都不涉及时区，它只管“物理时间长度”。如果你误把“每天上午 9 点”这种时刻当成时长去转毫秒，逻辑就完全错了——那是 LocalTime 或 ZonedDateTime 的事。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
