断点不生效主因是launch.json配置错误、node未被vscode调试器识别或typescript source map未正确映射；需验证path、program路径、sourcemaps、outfiles及resolvesourcemaplocations配置。
断点不生效，八成不是代码问题，而是 launch.json 没配对、node 不在 VSCode 的 PATH 里，或者你正在调试 TypeScript 却没让 source map 走通——这三件事没理清，点再多红点也没用。
断点点了没反应？先确认 node 命令能不能被调试器看见
VSCode 调试器启动时，会自己去 PATH 里找 node。它不读你的 shell 初始化文件（比如 ~/.zshrc），所以即使终端里 node -v 正常，调试器也可能报 Cannot find runtime 'node' on PATH。
- macOS/Linux：运行
which node得到路径（如/opt/homebrew/bin/node），然后在.vscode/settings.json中加："terminal.integrated.env.osx": { "PATH": "/opt/homebrew/bin:${env:PATH}" } - Windows：重装 Node.js 时务必勾选 “Add to PATH”，或手动把
C:\Program Files\nodejs\加进系统环境变量 - 改完必须彻底退出 VSCode（包括托盘进程），再从终端执行
code .启动——直接双击打开不会继承终端 PATH - 验证方式：在 VSCode 内置终端（
Ctrl + `）里跑node -v，有输出才算过关
launch.json 里最关键的三个字段不能错
删掉所有花哨配置，只留最核心的三项，就能跑通。其他字段填错反而会让调试静默失败。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
"type": "node"—— 别写"pwa-node"，尤其老项目或 CommonJS 场景下容易 fallback 失败 -
"request": "launch"—— 表示“我来启动进程”，不是“我去连别人”。只有你手动跑了node --inspect-brk xxx.js才用"attach" -
"program": "${workspaceFolder}/src/index.js"—— 必须是真实存在的、Node 可直接执行的 JS 文件路径；"./src/index.js"或"src/index.js"都不行，VSCode 不解析相对路径前缀
TypeScript 项目断点停在 .js 里？source map 链路断了
你在 src/index.ts 上打的断点变成空心红圈，说明 VSCode 根本没把编译后的 dist/index.js 和源码关联起来。
- 确保
tsconfig.json里有"sourceMap": true，且构建后生成了.js.map文件 -
launch.json中必须显式加："sourceMaps": true"outFiles": ["${workspaceFolder}/dist/**/*.js"] - 如果
.ts文件不在根目录（比如在packages/foo/src），还得加："resolveSourceMapLocations": ["${workspaceFolder}/packages/**/src/**", "!**/node_modules/**"] - ESM 项目记得在
package.json里写"type": "module"，否则import解析失败，连require都报Cannot find module
Express/Koa 路由断点不动？可能请求根本没走到那里
服务控制台显示 Listening on port 3000，但发请求后断点不触发、日志也不打——这不是调试配置问题，是中间件提前截断或路由没匹配上。
- 先在
app.use((req, res, next) => { ... })或错误处理中间件里设断点，确认请求是否进入应用层 - 检查
express.json()、body-parser是否因 payload 过大或格式错误直接返回 400 - 确认
program指向的是实际被npm start执行的文件，常见坑是package.json里写的是"main": "bin/www"，但launch.json还指向index.js - 端口冲突（
EADDRINUSE）会导致进程启动失败，VSCode 看似“没反应”，其实是调试器连进程都没起来
最易被忽略的一点：调试器连上的不是你认为的那个进程。比如同时开了两个 --inspect 实例，第二个会因端口占用崩溃；又或者你在终端手动跑了 npm start，却试图用 launch 模式去连——它根本没开调试端口。
