settimeout 传入超过 2147483647 毫秒（约 24.8 天）的延迟值会立即执行，因其被强制转为 32 位有符号整数后发生溢出：浏览器设为 0 毫秒，node.js 设为 1 毫秒；验证可用对比代码；长期任务需分段调度或交由服务端处理。
传入超过 2147483647 毫秒（约 24.8 天）的延迟值时，回调函数会立即执行，而不是等待预期时间。这不是随机 Bug，而是由底层整数表示机制决定的确定性行为。
为什么会立即执行？
浏览器和 Node.js 内部将 delay 参数强制转换为 32 位有符号整数。该类型最大值为 2147483647；一旦超出，就会发生溢出：
- 若结果被解释为负数（如最高位为 1），规范要求将其设为 0
- 若截断后为 0 或极小正数，实际效果等同于
setTimeout(fn, 0) - Node.js 的处理略有不同：超限 delay 会被统一设为 1 毫秒，但依然远小于预期
如何验证这个现象？
可以直接运行对比代码：
-
setTimeout(() => console.log('24.8天后'), 2147483647)—— 正常延迟 -
setTimeout(() => console.log('立刻触发'), 2147483648)—— 几乎立即输出 -
setTimeout(() => console.log('极大数'), 1e15)—— 同样立刻执行
长期延迟任务该怎么写？
不能依赖单次 setTimeout 实现月级、年级延迟。可靠做法是分段调度或交由外部系统处理：
- 用递归链式调用，每次不超过 2147483647ms，逐步推进总延迟
- 服务端场景优先使用数据库定时任务（如 PostgreSQL 的 pg_cron）或消息队列延迟投递
- 前端持久化场景可结合 IndexedDB 存储计划时间，每次页面加载检查是否到期
还有哪些隐含限制要注意？
即使 delay 值合法，实际执行时间也不精确：
- 浏览器对非活跃标签页会节流，timeout 最多每秒触发一次
- 最小 delay 受规范限制：HTML5 要求不低于 4ms（旧版为 10ms）
- CPU 高负载、主线程阻塞都会造成明显延迟，定时器不保证准时
