VSCode调试node_modules需绕过source map限制：设"sourceMaps": false、"skipFiles": ["/**"]，禁用outFiles干扰；TS包推荐npm link源码并启用sourceMap；断点失效优先查resolveSourceMapLocations、Node版本及模块缓存。
VSCode 调试 node_modules 里没 source map 的 JS 包
默认情况下，VSCode 不会进 node_modules 里的代码——不是它不想，是 V8 引擎根本没把那些文件映射到原始源码，断点直接“悬空”。尤其遇到纯 JS（非 TypeScript 编译）但又没带 sourceMappingURL 注释的包，debugger 或点击断点都无效。
实操关键是绕过“必须靠 source map 才能映射”的限制，让调试器把压缩/编译后代码当“源码”用：
- 在
.vscode/launch.json的配置里加"skipFiles": ["<node_internals>/**"]</node_internals>（去掉默认跳过内置模块的干扰） - 显式禁用 source map 检查：
"sourceMaps": false，强制用当前加载的 JS 文件本身设断点 - 确保
"outFiles"不包含node_modules相关路径，否则 VSCode 会主动忽略 - 如果包是 ESM 格式且用了
exports字段，检查package.json是否导出了main或browser字段——VSCode 调试器只认这些入口
调试 TypeScript 编译后的 node_modules 包（如 @types + lib）
TypeScript 包常带 .d.ts 和编译后的 lib 目录，但 node_modules 里通常不放 .ts 源码或 .map 文件。想断进 TS 原始逻辑，得手动补 source map 或改引用方式。
最稳的路是：不依赖 npm install 后的产物，而是用 npm link 或 yarn link 把包源码软链接进来：
- 进该包根目录，运行
npm link - 进你的项目目录，运行
npm link <package-name>（比如npm link axios） - 确认
node_modules/<package-name>是个软链接，指向本地源码目录 - 确保该包源码里有
tsconfig.json且"sourceMap": true已启用 - 启动调试时，VSCode 就能读到
.ts文件和对应.js.map，断点自然生效
断点进了 node_modules 却无法停住？检查这三个地方
常见现象：断点变成空心圆、hover 显示 “Unbound Breakpoint”，或者控制台输出 Breakpoint ignored because generated code not found。
优先排查这三项：
-
launch.json中"resolveSourceMapLocations"如果存在，确认它没 excludenode_modules（比如["!**/node_modules/**"]就是典型错误配置） - Node.js 版本是否 ≥ 14.18？旧版本对 ESM + source map 支持不全，容易丢映射
- 包是否用了动态
require()或import()加载？这种运行时加载的模块，VSCode 默认不预解析，需在launch.json加"trace": true看日志确认模块是否被加载 - 检查
node_modules下该包的package.json有没有"sideEffects": false——Webpack 类打包工具可能已 tree-shake 掉你断点所在的模块，实际没进内存
为什么有时改了 node_modules 里的代码却没生效？
不是 VSCode 的问题，是 Node.js 模块缓存机制在起作用：只要 require() 过一次，模块就被缓存在 require.cache 里，后续所有 require 都返回缓存对象。
调试中临时修改 node_modules 源码想立刻验证？必须清缓存：
- 在调试终端里手动执行
require('module')._cache = {}（仅限 Node.js delete require.cache[require.resolve('xxx')]） - 更可靠的做法：重启调试会话（
Ctrl+Shift+F5），避免残留缓存 - 如果用的是 ESM（
import），注意import不受require.cache控制，但 Vite / Webpack 开发服务器可能做了自己的模块缓存，需手动 HMR 或刷新页面
真正麻烦的永远不是怎么断进去，而是断进去之后，发现代码早被优化掉、被缓存住、或者压根没执行到——这时候得看 console.log 和调用栈，而不是只盯着断点形状。
