是死锁。表现为断点卡住、cpu先飙升后归零、新请求无响应，且日志出现session_id not found或output lock提示，本质是事件循环卡死导致v8 inspector心跳断连。
断点卡住但CPU飙升又归零，是不是死锁？
不是所有断点不继续都叫死锁。如果你在 VSCode 里 F5 启动、断点命中后程序不动，同时终端里 CPU 先冲到 95%+、几秒后掉到 0%，且后续请求全无响应——这极大概率是异步任务互锁型死锁，本质是事件循环卡死，V8 Inspector 心跳断连，调试器失去控制权。
常见干扰项包括：fs.readFileSync 这类同步阻塞、while(true) 长循环、未处理的 Promise.reject() 沉默失败。它们也会卡住，但不会触发 session_id not found 或 output lock 这类关键词。
- CommonJS 循环 require 导致的“半初始化”通常报
TypeError: xxx is not a function，不会伴随 CPU 飙升 - Ctrl+C 没反应 ≠ 死锁，更可能是阻塞在 native 层（如
child_process.spawnSync） - 真正死锁时，
process.uptime()停止增长，kill -USR1 <pid></pid>无法触发堆快照
launch.json 配置必须避开的三个硬坑
死锁还没开始查，调试器就连不上，往往是因为 launch.json 写错了根本路径或模式。VSCode 不会提示“你配错了”，只会静默失败。
-
"program"必须是绝对路径变量："${workspaceFolder}/dist/index.js"✅，写成"src/index.js"或"./src/index.js"❌（调试器找不到文件） - TypeScript 项目别直接指向
.ts文件——除非已配preLaunchTask编译，否则报Cannot launch program because corresponding JavaScript cannot be found - Express/Koa 类服务优先用
"request": "attach"模式，避免EADDRINUSE或子进程fork导致启动失败；attach模式需手动加--inspect-brk到启动命令中
用 Ctrl+C + 日志关键词快速验证死锁
卡死时别干等，立刻按 Ctrl+C 中断进程，看终端最后几行输出。这是最轻量、最可靠的初步判断方式。
- 出现
session_id not found、Unknown state session、output lock等关键词 → 强烈指向异步互锁型死锁 - 出现
RangeError: Maximum call stack size exceeded→ 可能是 symlink 循环或递归过深 - 出现
TypeError: Cannot read property 'xxx' of undefined→ 更可能是 CommonJS 循环引用或模块未初始化完 - 另开终端执行
codexsession list，若返回多个状态为Alive但实际超时的会话 ID，基本坐实死锁
如何让调试器在死锁前就捕获事件循环异常
默认 launch.json 不暴露底层调度细节。要让 VSCode 在僵死前预警，得主动启用 inspector 并开启事件追踪。
- 在
launch.json的runtimeArgs中加入：--inspect-brk=9229和--trace-event-categories v8,disabled-by-default-node（后者是关键，标记 loop/timer/idle 阶段） - 加
"env": {"NODE_OPTIONS": "--trace-events-enabled --trace-event-file=./tracing.json"}，把事件写入文件，之后可用 Chrome 打开chrome://tracing加载分析 - 入口文件顶部插入延迟探测代码：
const start = performance.now(); process.nextTick(() => { const delta = performance.now() - start; if (delta > 50) console.warn('Event loop delay:', delta, 'ms'); }); - 调试启动后，在 VSCode 的
Debug Console里执行：require('perf_hooks').performance.eventLoopUtilization()，若active长期接近 0，说明事件循环已停滞
死锁排查最易被忽略的一点：它常发生在启动阶段，而非业务逻辑中。很多问题其实在 require() 链或 process.env 初始化时就埋下了，等断点打到路由层，早就晚了。
