断点不生效的根本原因是node.js的--inspect仅监听首次入口执行，而定时任务（如setinterval、node-cron）的异步回调脱离调试上下文；必须改用--inspect-brk启动或采用attach模式，并确保sourcemap正确映射、端口配置一致、避免字符串任务体。
为什么 node --inspect 启动后断点不生效
常见现象是：加了 debugger 或在 VSCode 编辑器里点了断点，但代码跑过就跳过了，调试器完全没响应。根本原因通常是定时任务（比如 setInterval、node-cron）启动后，主线程没被调试器持续挂住——Node 的 --inspect 默认只监听首次入口文件执行，后续异步回调（尤其是延时触发的）可能脱离调试上下文。
实操建议：
- 必须用
node --inspect-brk启动（不是--inspect），让进程在第一行就暂停，等 VSCode 附加上去再继续 - 如果用了
pm2或其他进程管理器，它会绕过--inspect，直接改用 VSCode 的Attach to Node.js Process模式 - 确认
launch.json中的port和启动命令一致，默认是9229，但某些 Docker 或远程场景会被映射或占用
VSCode launch.json 怎么配才支持定时触发调试
关键不是“支持定时”，而是让调试器能捕获到定时回调里的代码执行。默认的 node 调试配置只管入口文件，对 setTimeout 或 cron.schedule 内部的函数调用无感知，除非它们在同一个 JS 执行上下文中。
实操建议：
- 用
attach模式比launch更可靠：先启动带--inspect=0.0.0.0:9229的 Node 进程，再在 VSCode 里选Attach to Node.js Process -
launch.json中必须设"protocol": "inspector"（旧版legacy协议不支持现代 async/await 断点） - 如果定时任务由子进程触发（如
child_process.fork），需额外加--inspect-port=9230并为子进程单独配置 attach
node-cron 或 node-schedule 断点失效怎么办
这些库内部大量使用 setTimeout 和闭包，V8 的调试器有时无法把回调函数和原始源码位置准确映射，尤其当任务定义在模块顶层、或通过字符串表达式注册时（如 cron.schedule('0 * * * *', 'console.log(1)')）。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
实操建议：
- 绝对避免字符串形式的任务体，改用函数：
cron.schedule('*/10 * * * *', () => { debugger; console.log('hit'); }) - 确保
sourceMap开启：TS 项目编译时加"sourceMap": true，JS 项目若用了 Babel，也要配sourceMaps: true - 在定时回调函数第一行手动加
debugger，比依赖编辑器点击断点更稳定 - 检查 VSCode 的
Debug Console是否报Could not load source map，有则说明路径映射失败，需调整outFiles或webRoot
远程容器或 WSL 里调试定时任务的坑
本地 VSCode 连不上容器或 WSL 里的 --inspect 端口，最常卡在端口未暴露或网络策略拦截。不是代码问题，是连接链路断了。
实操建议：
- 容器启动必须加
-p 9229:9229且 Node 启动参数写成--inspect=0.0.0.0:9229（不能是127.0.0.1，否则容器内 localhost ≠ 宿主机） - WSL2 需在 Windows 主机防火墙放行
9229端口，并确认localhost:9229能从浏览器访问http://localhost:9229/json - VSCode 的
Remote - WSL或Dev Containers扩展启用后，调试配置自动适配，此时应优先用 Remote Attach 而非本地 launch
真正麻烦的不是怎么设断点，而是定时任务往往跨多个 tick、多层 call stack，一旦漏掉 debugger 或 source map 错位，就只能靠 console.log + 时间戳硬排。留个心眼：每次修改定时表达式后，务必重启进程，别指望热更新能重载 inspect 上下文。
