JavaScript定时器需手动增强容错性：回调内必须try/catch、避免setInterval堆叠而改用递归setTimeout、清除机制覆盖所有退出路径、不依赖延时精度并用Date.now()校验真实耗时。
JavaScript 定时器本身不具备容错能力，它的执行逻辑是“发出去就不管”，错误会直接抛出、不被捕获、不中断主线程——但你可以通过结构化设计让它变得健壮。
定时器回调必须自带 try/catch
setTimeout 和 setInterval 的回调函数运行在独立的异步上下文中，外部的 try/catch 完全无效。一旦回调里出错（比如访问 undefined 属性、网络请求失败未处理），就会触发 uncaught error，可能中断后续执行或影响用户体验。
- 正确做法：每个定时器回调内部包裹 try/catch，并主动处理异常
- 示例：setTimeout(() => { try { doSomething(); } catch (e) { console.warn('定时任务异常:', e); } }, 1000);
- 尤其在操作 DOM、读取 localStorage 或调用外部 API 时，必须预判可能失败点
避免 setInterval 的累积失控
setInterval 不会因前一次回调未完成而跳过下一次，如果回调执行时间超过设定间隔，就会出现“堆叠执行”，造成内存暴涨或 UI 卡顿。
- 推荐替代方案：用 setTimeout 递归调用，确保上一次执行完再安排下一次
- 示例：function tick() { doWork(); setTimeout(tick, 1000); } tick();
- 若必须用 setInterval，应在回调开头加状态锁（如 flag = true / false）防止重入
清除机制要覆盖所有退出路径
定时器 ID 必须在组件卸载、状态变更、条件满足等所有可能场景下被 clearTimeout/clearInterval，否则会持续占用内存并偷偷执行。
立即学习“Java免费学习笔记（深入）”；
- 常见遗漏点：页面跳转、React 组件 unmount、Vue 组件 destroyed、fetch 超时后仍保留 timer
- 建议绑定清理逻辑到明确生命周期钩子，例如 React 中 useEffect 的 return 函数
- 可封装安全定时器工具函数，自动管理清除引用和防重复清除
延时精度不可靠，别依赖“准时”
浏览器最小延迟通常为 4ms（低于该值会被自动提升），且当主线程繁忙（如长任务、大量渲染）时，定时器实际触发时间会严重滞后，甚至被推迟数秒。
- 不要用 setTimeout 模拟高精度倒计时或动画帧；改用 requestAnimationFrame 或 Web Worker
- 对时效性敏感的任务（如心跳检测），应结合 Date.now() 计算真实耗时，而非只靠 delay 参数
- 可设置超时兜底逻辑：例如发起请求后启动 5s 定时器，若 Promise 未 resolve 就主动 reject
