根本原因是父进程未释放stdio句柄，导致vscode调试适配器无法接管调试协议流；应改用launch模式启动或确保目标进程孤立且stdio指向终端设备。
Node进程卡在“Debugger attached”但断点不生效
根本不是VSCode没连上，而是父进程（比如npm start、nodemon或shell脚本）还攥着stdin/stdout句柄，导致VSCode调试适配器无法接管调试协议流。此时Node虽开了--inspect端口，但stdin仍连在管道里，断点自然失效。
- 别用
Attach to Node Process，改用launch模式：在launch.json中设"request": "launch"，让VSCode直接启动Node，绕过所有父进程中介 - 必须Attach时，先确认目标进程是孤立的：执行
ps aux | grep node，看CMD列是否含npm、sh -c或bash -c——有就说明被壳层包裹，句柄未释放 - Linux/macOS下用
lsof -p <pid> | grep STD</pid>检查：若STDIN/STDOUT指向pipe或socket而非chr（终端设备），基本可断定句柄泄漏
终端执行node app.js后光标卡住、无输出
命令回车后光标停住不动，既不报错也不退出，大概率是Node进程已启动，但它的stdout/stderr被重定向到一个未关闭的管道，而管道另一端的父进程（如CI脚本、Makefile、或code-runner插件）已死，句柄却没释放，Node就阻塞在write()系统调用上。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 按
Ctrl+C中断后，立刻执行lsof -i :9229（默认inspect端口），确认是否有残留Node进程，有就kill -9掉 - 检查是否用了
child_process.spawn()类API启动子进程但没设{ stdio: 'inherit' }或{ detached: true }，导致子Node继承了父进程的stdio句柄 - 禁用
code-runner插件，改用集成终端手动运行node --trace-warnings app.js，看是否卡在某条console.log()或process.stdout.write()
VSCode调试启动后Node进程秒退
F5后进程一闪即逝，Debug Console里看不到任何日志——不是代码报错，而是Node启动后，因父进程（VSCode调试适配器）没及时接管其stdio，操作系统判定为“无人监听”，直接回收句柄并终止进程。
- 检查
launch.json中program路径是否正确，且不要写相对路径（如./node）或含中文/空格的路径（如D:软件 odejs ode.exe） - 更稳妥的做法是留空
runtimeExecutable字段，让VSCode自动从PATH查找；或填纯英文无空格绝对路径，如"C:\nodejs\node.exe" - 确保
terminal.integrated.env.windows已正确配置Node路径，否则VSCode可能根本找不到node可执行文件（尤其Windows + PowerShell组合下）
amqplib重复amqp.connect()导致EMFILE错误
每个amqp.connect()都会创建至少一个TCP socket和若干内部流对象。在循环中反复调用却不close()，句柄不会自动回收——不是“慢释放”，是根本不会释放，直到进程被OS杀掉（报EMFILE或EADDRINUSE）。
-
amqp.connect()必须全局只调用一次，返回的connection存为模块级变量或注入容器 - 所有
channel必须从该单例connection创建，并在使用完毕后显式调用channel.close() -
connection.close()不是同步完成的，必须await；且需监听error和close事件做重连兜底，不能静默丢弃旧实例
await connection.close()，而是忘记在进程退出前按channel → connection顺序逐个await关闭——一旦提前退出，所有未close()的连接都会变成僵尸句柄。
