Promise.prototype.finally 是处理无论成功或失败都必须执行的清理逻辑的理想工具，它不接收结果值、不影响链式传递、必定执行且天然隔离业务与资源管理。
Promise.prototype.finally 是处理“无论成功或失败都必须执行”的清理逻辑的理想工具，特别适合释放局部资源锁（如内存缓存锁、临时文件句柄、UI 禁用状态、数据库连接池中的租约等）。它不接收 Promise 的结果值，也不影响链式传递的值，天然隔离业务逻辑与资源管理。
为什么 finally 比 then/catch 更合适？
使用 then(onFulfilled).catch(onRejected) 需要重复写相同的释放逻辑，容易遗漏或不一致；而 finally 只写一次，且在 Promise settled（fulfilled 或 rejected）后**必定执行**，不依赖返回值，也不会因内部抛错中断（除非 finally 回调自身 throw，但通常应避免）。
例如：
✅ 推荐：锁在 finally 中统一释放acquireLock() .then(() => doWork()) .catch(err => handleError(err)) .finally(() => releaseLock()); // 一定执行❌ 风险：漏掉 catch 分支，锁未释放
acquireLock()
.then(() => doWork())
.then(() => releaseLock()) // reject 时不会走这里
.catch(err => {
handleError(err);
releaseLock(); // 必须手动补上，易疏忽
});
典型适用场景与写法要点
- UI 层加载锁：按钮禁用 + loading 状态，无论请求成功/失败都要恢复交互
- 内存缓存锁：对某个 key 加写锁（如防止重复提交），操作结束立即解锁，避免死锁
- 临时资源句柄：创建临时 DOM 节点、Canvas 上下文、Web Worker 实例等，需确保销毁
- 异步中间件锁：在请求拦截器中加锁（如防抖/节流锁），响应后必须清除
关键原则：锁的生命周期必须与 Promise 生命周期严格对齐。若锁是函数内声明的局部变量（如 const lockId = generateId()），需确保 finally 能访问到它 —— 通常通过闭包或提升作用域实现。
带局部锁 ID 的完整示例
以下是一个封装了「局部锁」获取、使用、释放的实用模式：
function withLocalLock(key, operation) {
const lockId = Symbol('lock'); // 或用字符串 ID，保证唯一
return acquireLock(key, lockId)
.then(() => operation())
.catch(err => {
console.warn(`Operation failed under lock ${lockId}:`, err);
throw err;
})
.finally(() => releaseLock(key, lockId)); // 局部 lockId 在闭包中可用
}
// 使用
withLocalLock('user-profile', () => fetchUserProfile())
.then(data => render(data))
.catch(err => showErrorMessage(err));
注意：此处 acquireLock 和 releaseLock 应设计为支持同一 key 下多锁共存（例如基于 lockId 区分），避免误释放其他协程的锁。
注意事项与边界情况
-
finally不接收参数，无法直接获知 Promise 是成功还是失败；如需差异化处理（如仅失败时上报），应在catch中做，finally专注无条件清理 - 若
finally回调中抛出异常，会以该异常取代原 Promise 的结果（覆盖成功值或原有错误），因此清理逻辑应尽量避免 throw（可加 try/catch 包裹关键释放操作） - 对于需等待释放完成再继续的场景（如异步关闭文件），
finally不支持返回 Promise —— 此时应改用 async/await 显式控制流程，或用then().catch().finally()后接新链
