定时器回调异常需在内部用try/catch捕获并上报，配合window.error全局监听；必须throw Error实例，记录上下文如路由、traceId，优先用sendBeacon上报。

定时器回调（如 setTimeout、setInterval）中的异常无法被外层 try/catch 捕获，因为它们运行在独立的执行上下文和事件循环任务中。要安全处理这类异常，必须在回调内部主动防御，同时配合全局兜底机制。

在回调函数内加 try/catch

这是最直接、最可控的方式：把可能出错的逻辑包裹在 try/catch 中，并做有意义的错误响应。

• 每个 setTimeout 或 setInterval 的回调函数都应单独包裹，不能依赖外部作用域的 try/catch
• catch 中建议记录错误（console.error）、上报监控、或触发降级逻辑（如重试、关闭定时器）
• 避免空 catch；若选择静默吞错，需明确注释原因

统一监听 unhandledrejection 和 error 事件

定时器回调若抛出未捕获异常，会触发 window.onerror（不是 unhandledrejection，因不涉及 Promise），但仅限于非 Promise 场景：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• window.addEventListener('error', event => { ... }) 可捕获定时器、事件监听器、资源加载等同步/异步抛出的原始错误
• 注意：从 event.error 提取堆栈；若为空，则拼接 event.filename + ':' + event.lineno + ':' + event.colno
• 需调用 event.preventDefault() 阻止默认控制台警告（可选，不影响上报）

避免在定时器中 throw 原始字符串或非 Error 实例

throw 字符串（如 throw 'oops'）会导致 event.error 为 undefined，丢失关键调试信息：

• 始终 throw Error 实例（throw new Error('msg')），确保有 stack 属性
• 可在回调开头统一包装： try { /* 业务逻辑 */ } catch (e) { throw e instanceof Error ? e : new Error(String(e)); }
• 自定义错误类（如 TimeoutError）有助于后续分类统计

补充上下文并可靠上报

单靠捕获不够，错误日志必须带上下文才能定位问题：

• 在定时器启动前，记录当前路由、用户 ID（脱敏）、traceId、定时器用途（如 "cart-refresh-timer"）
• 上报时将这些字段打平到 payload，例如：{ type: 'timer-error', timerId: id, route: location.pathname, ... }
• 优先用 navigator.sendBeacon() 上报；不可用时 fallback 到 new Image().src = url 或 fetch(..., { keepalive: true })

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南