node.js调试断点生效需满足四条件：设在原始源码而非编译文件；ts项目开启sourcemap并启用webstorm源码映射；优先在中间件函数内设断点；attach模式时host须用0.0.0.0而非127.0.0.1。
断点设在哪才真正生效
Node.js 调试时断点“不命中”是最常见的假性失败——你以为代码跑到了，其实根本没进调试上下文。根本原因在于：WebStorm 只能对 require 进来的、被 V8 实际执行的 JS 文件设有效断点；对 eval、new Function、动态 import() 加载的代码，或被 Babel/Webpack 处理后映射错乱的源码，断点大概率失效。
- 确保你在原始源文件（如
app.js、server/index.ts）里设断点，而不是编译后的dist/下文件 - TypeScript 项目必须开启
sourceMap: true，且 WebStorm 的 Node.js 运行配置中勾选Enable source maps - Express/Koa 等框架的中间件函数里设断点更可靠，比如在
router.get('/user', (req, res) => { ... })内部，而非顶层app.listen()行
Debug 按钮点下去却没反应？检查这三件事
点击 Debug 图标后控制台一闪而过、进程秒退、或者 Debug 工具窗口压根不弹出——大概率不是环境问题，而是配置漏项。
- 确认
Node.js和JavaScript Debugger插件已启用（Settings | Plugins→ 检查 Installed 标签页） - 运行配置里
Node interpreter必须指向真实 Node 可执行路径（如/usr/local/bin/node），不能是空或默认的“Project default”却未配置解释器 - 如果你用
npm start启动，别直接 Debugpackage.json脚本——先右键该脚本选择Run 'start'确认能正常启动，再改用Node.js类型配置，把Working directory设为项目根目录，JavaScript file填./bin/www或实际入口
如何调试已运行的 Node 进程（attach 模式）
微服务、Docker 容器或后台常驻进程没法重启，这时必须用 attach 方式接入调试器，否则只能干瞪眼。
- 启动目标进程时加参数：
node --inspect-brk=0.0.0.0:9229 ./index.js（--inspect-brk会阻塞到调试器连接才继续） - WebStorm 中新建
Run/Debug Configuration→ 选Attach to Node.js/Chrome→ Host 填localhost，Port 填9229 - 注意：如果进程在 Docker 里，宿主机要映射端口（
-p 9229:9229），且--inspect-brk的 host 不能写127.0.0.1（容器内无法回环） - attach 后断点仍需设在源码上，但 WebStorm 会自动匹配已加载模块——前提是源码路径与进程内
require.resolve()返回的路径一致
为什么 console.log 看不到，但断点能停住
日志“消失”不是调试器的问题，而是输出流被重定向或缓冲了。尤其在用 morgan、winston 或管道启动（npm start | bunyan）时常见。
- WebStorm 的
Console标签页只捕获标准输出（stdout/stderr），不捕获写入文件的日志；若你用fs.appendFile记日志，它不会出现在 Console 里 - Node.js 的
console.log在某些场景下会缓冲（比如子进程、TTY 判断失败），加process.stdout.flush()强制刷出（仅限 Node ≥18.17+） - 更稳的办法：在断点暂停时，用 Debug 工具窗口的
Evaluate Expression（Alt+F8）手动执行console.log('debug:', someVar)，结果直接打印在 Console
--inspect-brk=127.0.0.1:9229 卡死在容器里，连不上。
