定时器回调内抛出的异常不会冒泡至外层或中断主线程，仅终止当前任务并被浏览器作为未捕获异常报告；必须在回调内用 try/catch 捕获，因定时器任务是事件循环中独立的执行单元。
定时器回调函数内部抛出的异常，不会向上冒泡到调用栈外层，也不会中断主线程后续代码执行，而是直接终止当前回调的执行，并被浏览器捕获后作为未捕获异常报告（如显示在控制台），但不会触发 window.onerror 或 Promise rejection 事件（除非显式监听）。
异常发生在 setTimeout/setInterval 回调里会怎样？
JavaScript 的定时器回调属于“任务（task）”，运行在独立的执行上下文中。一旦回调内抛出错误，该错误仅限于当前任务内终止
- 错误不会传播到定时器设置语句所在的代码块（比如不会让
setTimeout(fn, 100)外面的 try/catch 捕获） - 后续已排队的定时器任务仍会照常执行（除非回调本身被阻塞或被 clearTimeout/clearInterval 清除）
- 浏览器将该错误视为“未捕获的运行时异常”，写入 console.error，但不打断主线程
为什么异常不冒泡？
因为定时器回调是通过事件循环推入调用栈的，它与原始调用点没有调用链关系。相当于“新起点”执行，不是原函数的子调用：
-
setTimeout(() => { throw new Error('boom') }, 0)中的箭头函数，和它前面那行代码不在同一执行帧中 - 就像点击按钮触发的事件回调一样——错误只属于那个事件任务，不回溯到 addEventListener 那一行
- 这是事件循环模型决定的：每个宏任务（包括定时器回调）都是独立的执行单元
如何可靠捕获定时器内的错误？
必须在回调内部做防御性处理，外部无法代劳：
立即学习“Java免费学习笔记（深入）”；
- 用
try...catch包裹整个回调逻辑 - 对异步操作（如 fetch、Promise）配合
.catch()或await ... catch - 全局监听可补充兜底：
window.addEventListener('error', handler)能捕获同步错误；而window.addEventListener('unhandledrejection', handler)可捕获未处理的 Promise reject（但不覆盖定时器回调里的同步 throw）
对比：事件回调 vs 定时器回调的异常行为
二者在异常处理上表现一致——都属于独立任务，错误均不向外冒泡：
-
button.addEventListener('click', () => { throw 'click error' })→ 错误只停在 click 回调里 -
setTimeout(() => { throw 'timeout error' })→ 错误只停在 timeout 回调里 - 它们共享同一个规则：DOM 事件、定时器、setImmediate（Node）、postMessage 回调等，都是任务队列驱动，各自隔离
