finally 不接收上一个 Promise 的返回值，仅用于同步清理操作；其内部异步操作不会被等待，且作用域仅限于所挂载的 Promise 实例。
finally 不会接收上一个 Promise 的返回值，别指望它能拿到响应数据
finally 的设计目的就是「清理」，不是「转发」。它不接收参数，无论前面是 resolve 还是 reject，finally 回调里都拿不到结果或错误对象。
常见误用：在 finally 里试图读取 res.data 或判断 err.message —— 这会直接报 ReferenceError 或 undefined 错误。
- 想处理成功逻辑？用
then - 想处理失败逻辑？用
catch - 想关 loading、清缓存、发埋点？用
finally
finally 里的异步操作不会阻塞链式执行，小心副作用丢失
finally 内部如果返回 Promise（比如调用一个 API 或 setTimeout），这个 Promise **不会被等待**，后续的 then 或 catch 会照常执行，哪怕清理动作还没完。
例如：
fetch('/api/user')
.then(res => res.json())
.finally(() => {
return new Promise(resolve => setTimeout(resolve, 1000)); // 这个延迟不会阻塞后续
})
.then(data => console.log(data)); // 立刻执行，不等 1 秒- 需要等待清理完成？得手动把清理逻辑提前到
then/catch里，或者用async/await重构整个链 - 只是发个日志、关个 spinner？直接同步写就行，
finally天然适合这类无依赖操作
和 try/catch/finally 对比时，注意 Promise 链的“作用域”边界
JS 的 try/catch/finally 是语法块级作用域，而 Promise.prototype.finally 只作用于它所挂载的那个 Promise 实例——不是整条链。
典型陷阱：
Promise.resolve()
.then(() => fetch('/a'))
.then(res => res.json())
.catch(err => console.error('fetch failed:', err))
.finally(() => console.log('done')); // 这里只捕获前一个 then 的 reject，不包含 fetch 本身的 network error-
fetch抛出网络异常（如断网）时，若没在第一个then前加catch，会跳过后续所有then，但依然进入finally - 真正“全覆盖”的 finally，得确保它挂在最外层 Promise 上，且前面没有未捕获的 reject 漏出去
- 更稳妥的做法：把请求包装进
async函数，用原生try/catch/finally控制流
finally 在 Axios 中的等效写法是 interceptors.response.use + .finally，但要注意拦截器优先级
Axios 本身不提供 finally，但你可以用响应拦截器模拟，不过得留意拦截器执行时机早于用户链上的 finally。
比如：
// 全局拦截器（先执行）
axios.interceptors.response.use(
res => res,
err => { /* 处理错误 */ throw err; }
);
<p>// 用户代码（后执行）
axios.get('/user').finally(() => hideLoading()); // 这里才关 loading- 拦截器适合统一日志、token 刷新；
finally更适合组件级副作用（如 React 中 setState） - 如果拦截器里抛出了新错误，用户的
catch仍能捕获，但finally仍会执行 - 不要在拦截器里做耗时操作，否则会拖慢所有请求的
finally触发时机
真正容易被忽略的是：finally 的执行不保证与 UI 更新同步，尤其在 React 中直接 setState 可能触发 warning —— 它不感知组件是否已卸载。这种时候得加个 isMounted 判断，或者改用 useEffect 清理函数。
