断点命中但程序卡住不一定是死锁；若cpu先飙升至95%+后骤降为0%、请求无响应、debugger attached但断点无高亮，才极可能是异步任务互锁型死锁，需通过ctrl+c查看session_id或output lock等关键词验证，并排除commonjs循环引用（表现为typeerror）及调试配置错误（如launch.json中program路径无效或未启用--inspect）。

断点命中但程序卡住，是不是死锁？

不是所有卡顿都是死锁，但如果你在 VSCode 里打上断点、F5 启动后进程停在某一行不动，且 CPU 占用持续 95%+、几秒后骤降为 0%，同时后续所有请求无响应——这极大概率是异步任务互锁型死锁，而非同步阻塞或 IO 等待。

CommonJS 循环 require 导致的“半初始化”也会卡住，但它通常表现为 TypeError: xxx is not a function 或读取 undefined 属性，不会伴随 CPU 飙升；而异步死锁会触发 V8 的事件循环停滞，调试器连不上、console.log 都可能不输出。

• 确认现象：终端里看到 Debugger attached. 但断点处无高亮、无暂停，且 node --inspect-brk 启动后几秒内 CPU 归零
• 排除干扰：关掉 PM2、nodemon 等进程管理器，直接用 node --inspect-brk index.js 启动，确保调试通道干净
• 快速验证：在卡死状态下按 Ctrl+C，看日志末尾是否残留 session_id not found、Unknown state session 或 output lock 相关关键词

VSCode 调试器连不上，先查 launch.json 和运行时参数

死锁常被误判为“调试器没连上”，其实根本原因是 Node 进程压根没进入可调试状态——它卡在启动阶段，连 --inspect 服务都没起来。

jinn-node

在Jinn网络为自主项目工作赚取代币奖励，让闲置的OpenClaw代理开始工作。

下载

• launch.json 中必须设 "request": "launch"，且 "program" 指向真实存在的 JS 入口文件（如 "${workspaceFolder}/dist/index.js"），不能是 npm start 或 ts-node 命令
• 别依赖 attach 模式：除非你手动加了 --inspect-brk 到 npm script 里，否则 npm start 启动的进程默认不暴露调试端口
• 检查 Node 版本：VSCode 调试器对 async_hooks 有强依赖，Node v24.16.0）可能无法挂起事件循环，导致死锁时调试器完全失联
• 验证 PATH：在 VSCode 内置终端执行 node -v，若成功但在调试时报 Cannot find runtime 'node' on PATH，说明调试器没继承 shell 环境变量，需在 .vscode/settings.json 中显式注入 PATH

定位异步锁持有关系，靠日志 + CodeGeeX 快速反推

人工扫 Promise 链效率极低，真正有效的办法是让工具帮你读内存快照和锁状态。

• 复现卡死场景后，在终端按 Ctrl+C 中断，复制最后一段报错或状态提示（含 session_id、output lock、Alive 等关键词）
• 在 VS Code 中右键终端 → 选择 使用CodeGeeX解释，它会自动识别出“任务 A 在等 lock，任务 B 持有 lock 并等待 session 更新”这类关系
• 若没装插件，可手动执行 codexsession list，看是否有多个 Alive 但超时的会话 ID —— 这是典型的互锁证据
• 别信 IDE 的“跳转到定义”：它只解析静态字符串，无法反映运行时实际的 await 执行顺序和锁竞争路径

修复前先确认是不是 CommonJS 循环引用

很多“死锁”其实是 CommonJS 模块加载期的循环依赖，表现相似但根源不同，修复方式也完全不同。

• 在每个疑似模块顶部加 console.log('loading', module.id)，运行后观察输出是否出现闭环（如 ./a.js → ./b.js → ./a.js）
• 更准的方法：在模块开头打印 Object.keys(module.exports)，如果某个模块被 require 时 exports 是空对象，就确认它是循环链中被提前加载的那一方
• ESM 不会出现这种问题，因为 import 是静态绑定；CommonJS 是动态执行，require() 返回的是当时已赋值的部分，所以容易得到 undefined
• 修复选延迟加载还是提取共享状态，取决于模块用途：工具类（logger/db）适合延迟加载，配置/常量类必须提取到独立 shared.js

复杂点在于，异步死锁和 CommonJS 循环引用可能共存——比如一个模块在初始化时就发了个 await 请求，而该请求又触发了另一条 require 链。这时候得先解决循环引用，再排查锁竞争，顺序不能反。