定时器清理需先用clearInterval/clearTimeout停止任务，再用Promise.finally收尾状态；避免内存泄漏和请求堆积，finally必须挂载链末端且只做同步清理。
定时器本身不直接参与资源清理，但它常作为触发清理的“时间条件”出现；真正执行清理动作的，是 clearTimeout/clearInterval 和 Promise.finally 这两类机制——前者负责中断定时任务本身，后者负责收尾异步流程中的 UI 或状态。
定时器清理：先停任务，再清状态
setInterval 一旦启动，会持续执行，直到被显式清除。若不清理，回调函数长期驻留，闭包中引用的变量无法被垃圾回收，容易造成内存泄漏。
- 用 clearInterval 清除重复定时器，必须传入原始返回的 timer ID
- 在组件卸载、请求完成或条件达成时及时调用，不要依赖“自动结束”
- 避免在 setInterval 回调里直接发起未 await 的 axios 请求——它返回 Promise，但不会阻塞下一次执行，容易堆积未处理的请求
Promise.finally：守好整个异步链的终点
当异步操作（如 fetch + setInterval 轮询）需要统一收尾时，finally 是最合适的出口：它不关心成功或失败，只确保 loading 关闭、按钮还原、定时器终止等动作一定发生。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 必须挂载在 Promise 链末端，且前面不能被 catch 截断，否则失败路径进不去 finally
- 里面只做同步清理，比如 button.disabled = false、setLoading(false)，不读取 data、不判断 err、不发起新 fetch
- 如果轮询逻辑封装在 Promise 中（例如封装成一个返回 Promise 的 startPolling 函数），那么它的 finally 就天然覆盖整个轮询周期的收尾
典型组合场景：轮询+清理
比如轮询接口直到返回 success，期间显示 loading、禁用按钮，完成后统一还原：
立即学习“Java免费学习笔记（深入）”；
- 用 setTimeout 模拟轻量轮询更可控（避免 setInterval 堆积）
- 每次请求用 fetch + .then/.catch 处理响应，用 .finally 统一关 loading
- 成功或失败后，主动 clearTimeout，并在 finally 中还原 UI 状态
- 不把清理逻辑写在 then 或 catch 里——那样某一分支漏写就会导致状态残留
别让定时器干扰异步清理时机
setTimeout 的延时只是“至少等待”，不是精确时刻；若主线程正忙（如长循环、大量渲染），回调会被推迟。这意味着依赖 setTimeout 做“延后清理”的逻辑可能滞后，不如用 Promise.finally 可靠。
- loading 状态应由异步操作生命周期决定，而不是靠 setTimeout 延迟关闭
- 想实现“请求超时后自动取消”，要用 AbortController，而不是 setTimeout 后手动 reject
- clearTimeout 不影响已进入队列但尚未执行的回调——它只是不让后续回调再入队
