setTimeout和setInterval本身就是宏任务，每次调用后回调在至少delay毫秒后被注册进宏任务队列，待当前调用栈清空且所有微任务执行完毕后由事件循环调度执行；实际延迟受主线程负载、后台节流等影响，并不精确。
setTimeout 和 setInterval 本身就是宏任务，不是“属于”某种宏任务，而是 JavaScript 中最典型的宏任务来源。
它们怎么被当作宏任务调度
每次调用 setTimeout(fn, delay) 或 setInterval(fn, delay)，JS 引擎不会立刻执行 fn，而是：
- 在至少 delay 毫秒后，把回调函数注册为一个待执行的宏任务；
- 该任务被放进宏任务队列（macrotask queue）；
- 等当前调用栈清空、所有已排队的微任务（如 Promise.then、queueMicrotask）全部执行完，事件循环才从宏任务队列里取出它来执行。
实际执行时机并不精确
delay 只是“最小等待时间”，不是保证延迟。真实触发可能更晚，原因包括：
- 主线程正忙（比如运行长循环或大量 DOM 操作），定时器回调只能等它结束；
- 页面处于后台标签页时，浏览器会节流：setTimeout 最小间隔被拉长到 1000ms；
- 系统负载高、CPU 资源紧张，也会影响计时精度。
和微任务的配合关系
宏任务执行完后，会立即清空全部微任务队列——这是关键节奏。例如：
setTimeout(() => {
console.log('宏任务');
Promise.resolve().then(() => console.log('微任务'));
}, 0);
输出一定是：先“宏任务”，再“微任务”。因为微任务是在本轮宏任务结束后、下一轮宏任务开始前强制执行的。
如何更可靠地控制执行时机
- 别依赖 setTimeout(…, 100) 一定在 100ms 后触发，可用 performance.now() 在回调里记录真实时间，做动态补偿；
- 及时用 clearTimeout / clearInterval 清理不用的定时器，避免内存泄漏或重复执行；
- 对非紧急任务，考虑用 requestIdleCallback 替代，它由浏览器按帧预算主动调度，更省资源；
- 需要“尽可能快但不打断当前流程”时，可在 setTimeout 回调里用 queueMicrotask 延伸轻量逻辑。
