finally是UI清理最直接方案，它不接收上一Promise结果、不中断链式流程、保证无论fulfilled或rejected都执行，且不改变Promise状态，适合无条件收尾动作。
finally 是处理 UI 清理逻辑最直接的方案，但它不接收上一个 Promise 的结果，也不能中断链式流程 —— 这恰恰是它适合做「收尾动作」的原因。
为什么不能用 then 和 catch 替代 finally
很多人试图在 then 和 catch 里分别写 loading 关闭、按钮重置等逻辑，结果导致重复代码或漏掉错误分支。更隐蔽的问题是：如果 catch 中抛出新错误，后续 then 不会执行，但 UI 状态可能已卡死。
-
finally保证执行，无论 Promise 是 fulfilled 还是 rejected，甚至被 reject 后又在catch中 recover 了也照样触发 -
finally不改变 Promise 状态 —— 它返回的 Promise 类型与上游一致，不会把成功变成失败，也不会吞掉错误 - 它不接收参数，所以天然避免误读响应体或错误对象（比如把
error.message当成数据用）
finally 内部无法访问响应或错误，怎么安全清理 UI
UI 清理动作本身通常不需要原始数据（比如关 loading、设按钮为可用），但如果需要根据请求结果做差异化清理（如仅失败时弹 toast），就不能全压在 finally 里。
- 把「依赖结果的逻辑」留在
then/catch中，只把「无条件执行」的部分（setLoading(false)、button.disabled = false）挪进finally - 避免在
finally中调用异步操作（如await apiLog()），它不会等待，可能导致清理提前完成 - 如果必须发日志或埋点，用
Promise.resolve().then(() => ...)包一层，确保不阻塞主链
和 AbortController 配合时 finally 仍会执行吗
会。即使请求被主动 abort，fetch 返回的 Promise 也会以 reject 结束（AbortError），finally 依然触发。
const controller = new AbortController();
fetch('/api', { signal: controller.signal })
.then(r => r.json())
.catch(err => {
if (err.name === 'AbortError') console.log('请求已取消');
})
.finally(() => {
setLoading(false); // ✅ 这里仍会执行
});
controller.abort(); // 触发 catch + finally
- 注意：某些旧版 polyfill 对 abort 的 rejection 处理不标准，建议用原生
AbortController（现代浏览器均支持） - 如果使用 Axios，它的
cancelToken已废弃，优先用signal，否则finally在 cancel 时可能不触发
真正容易被忽略的是：当 Promise 链中存在多个 finally，它们按顺序执行，但任意一个抛出异常都会让后续 finally 继续运行 —— 所以清理函数自己得防错，比如 document.getElementById('loading')?.remove() 比直接 getElementById(...).remove() 更安全。
