定时器回调中的错误无法被外层try/catch捕获，必须在回调内部用try/catch防御性处理，并配合window.onerror等全局监听兜底。
定时器本身不产生错误，但其中执行的代码出错时，错误不会向上冒泡到外层 try/catch，也不会中断主线程——它会直接触发未捕获异常机制，导致控制台报错、程序逻辑中断，甚至影响后续回调执行。
定时器回调里的错误无法被外部 try/catch 捕获
因为 setTimeout/setInterval 的回调是通过事件循环推入调用栈的异步任务，与定义它的同步代码不在同一条执行路径上：
- 外层 try/catch 在定时器启动后立即结束，对后续回调无感知
- 错误发生在任务队列中，此时调用栈早已清空
- 浏览器会将其视为“uncaught exception”，触发 window.onerror（若已注册）
正确做法：在回调内部做防御性处理
必须把错误处理逻辑显式写进定时器回调里，而不是指望外层兜底：
- 用 try/catch 包裹回调体内的关键操作，尤其是可能抛错的 JSON.parse、DOM 访问、计算逻辑等
- 避免在 catch 中静默吞掉错误；至少 console.error 或上报监控系统
- 若需传递错误，可配合 Promise 封装，让错误能被 .catch() 或 await 捕获
补充兜底：监听全局未捕获异常
作为最后一道防线，建议设置 window.onerror 和 window.addEventListener('unhandledrejection')：
立即学习“Java免费学习笔记（深入）”；
- window.onerror 可捕获定时器、事件监听器等传统异步场景中的同步错误
- 注意：它接收的是错误信息字符串、脚本 URL、行号等，不是 Error 对象实例
- 搭配 sourcemap 和用户行为日志，能有效定位线上问题
避免常见误区
这些写法看似合理，实际无效：
- 对 setTimeout 调用本身加 try/catch —— 它返回 timer ID，不会抛错
- 在回调里 throw 错误却不处理 —— 直接崩溃，且无法被上层感知
- 依赖 Promise.then().catch() 包裹 setTimeout —— 若没显式 reject，错误仍会漏掉
