javascript中不存在传统异步死锁，但存在因promise相互等待、未正确终态或同步阻塞导致的逻辑卡死现象；常见于构造器内await未完成promise、循环调用无终止条件及错误同步等待等场景。
JavaScript 中严格来说不会发生传统意义上的异步死锁（如线程抢占式锁导致的循环等待），因为 JS 是单线程、事件驱动、无阻塞 I/O 的运行环境，没有可被“持有并等待”的互斥锁原语。但开发者常把一种特定场景误称为“异步死锁”：即多个 Promise 因相互等待、未正确 resolve/reject 或执行流卡在同步逻辑中，导致整个异步链停滞、UI 冻结、后续代码永不执行——表现为逻辑上“卡住”，效果类似死锁。
常见诱因：相互依赖的 Promise 未解耦
当两个或多个 Promise 在构造时就隐式依赖对方完成，且缺乏超时、兜底或解耦机制，就容易陷入“谁先 resolve？谁等谁？”的僵局。典型模式如下：
-
Promise 构造器内同步调用 await 另一个未完成的 Promise：例如在
new Promise((resolve) => { ... })的 executor 中 await 一个尚未 resolve 的变量，而该变量又依赖当前 Promise 完成 —— 这会阻塞 Promise 创建，导致它永远无法 resolve。 - 循环依赖的 async 函数调用链：A 调用 await B()，B 调用 await C()，C 又调用 await A()，且中间无条件跳出（如缓存、状态判断、超时）。
-
错误地在同步上下文中“等待”异步结果：比如试图用
let res = await somePromise写在非 async 函数里（语法报错），或更隐蔽地——用somePromise.then(...).catch(...)但忘记 return 新 Promise，导致链断裂、后续逻辑不触发。
如何排查：看执行流是否“断在中间”
不是查“锁”，而是查“Promise 是否悬而未决、链是否中断、控制台是否有未处理拒绝”：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
加日志定位挂起点：在每个 Promise 创建前、
then/catch入口、async 函数开头/结尾打console.log('A start')、console.log('A end')。若看到 “A start” 但没 “A end”，说明它卡在内部 await 或未 resolve 的 Promise 上。 -
检查未处理的 Promise 拒绝：开启浏览器 DevTools → Console → 勾选 “Pause on caught exceptions” 和 “Uncaught Exceptions”，同时监听
unhandledrejection事件：window.addEventListener('unhandledrejection', e => console.error('Unhandled:', e.reason));。静默失败常是死循环或 reject 被吞掉的信号。 - 用 Performance 面板观察任务队列：录制一段操作，查看是否有长时间运行的 task（>50ms）、microtask 队列持续堆积（大量 pending Promise.then 回调未执行），这暗示 microtask 链未收敛。
预防与修复：打破隐式依赖
核心原则：Promise 构造应尽量“自包含”，避免在 executor 中 await 外部未确定状态；异步依赖需显式建模、设超时、加兜底。
-
用
Promise.race()强制超时：对任何可能卡住的 Promise 包一层超时保护：const safeFetch = () => Promise.race([fetch('/api'), new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), 5000))]); -
拆分“创建”与“使用”阶段：不要在 Promise 构造器里 await 另一个动态 Promise；改为先定义依赖，再统一启动：
const p1 = fetch('/a'); const p2 = fetch('/b'); Promise.all([p1, p2]).then(...); -
避免在非 async 函数中模拟 await：禁止写
let data; somePromise.then(d => data = d); return data;这类“伪同步”代码——data 永远是 undefined。必须用 async/await 或完整 Promise 链。 -
给循环调用加终止条件：如递归加载数据时，加深度限制或已加载 ID 缓存：
async function loadWithCache(id, depth = 0) { if (depth > 5 || loaded.has(id)) return null; ... }
本质上这不是死锁，而是异步流程设计缺陷。只要保持 Promise 创建轻量、依赖显式、错误可捕获、超时有保障，就能避开这类“假死锁”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
