vscode中puppeteer断点不生效是因为调试器未连接浏览器上下文，必须用pwa-chrome类型+attach模式通过cdp协议连接--remote-debugging-port暴露的websocket端口，而非node类型；需正确配置launch.json的type、request、url、webroot，并在puppeteer.launch()中显式添加--remote-debugging-port参数。
VSCode里断点不生效？检查 launch.json 的 type 和 request
断点灰掉、page.evaluate 里的代码无法单步，大概率是调试配置类型错了。VSCode 必须通过 Chrome DevTools Protocol（CDP）连接浏览器实例，不是跑 Node.js 进程本身。
-
type字段必须设为"pwa-chrome"，不能用"node"或"pwa-node" -
request必须是"attach"，不是"launch"—— Puppeteer 自己拉起浏览器，VSCode 只负责连上去 -
url填"http://localhost:9222"，不是你的测试网页地址 -
webRoot设为"${workspaceFolder}"，否则 source map 映射失败，断点打不到源码行
puppeteer.launch() 没暴露调试端口？加 args 才有效
devtools: true 只弹窗，不开放 CDP 接口；VSCode 连不上，等于没入口。关键在显式传参启动调试通道。
VSCode 1.118
下载
微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。
- 正确写法：
await puppeteer.launch({ headless: false, args: ['--remote-debugging-port=9222'] }) - 错误写法：
await puppeteer.launch({ headless: false, devtools: true })（VSCode attach 失败） - 端口被占时，改
9223要同步改launch.json的url和args，缺一不可 - Windows 下注意空格：
'--remote-debugging-port=9222'不能写成'--remote-debugging-port = 9222'
用 puppeteer-core 复用本地 Chrome 更稳
每次 puppeteer.launch() 都下载独立 Chromium，版本、缓存、扩展全隔离，调试时 localStorage、cookie、甚至 DevTools 断点状态都容易丢，导致“断点突然失效”。
- 推荐方案：手动启动 Chrome：
chrome --remote-debugging-port=9222 --no-sandbox - 代码里用
puppeteer-core连接：await puppeteer.connect({ browserWSEndpoint: 'ws://localhost:9222/devtools/browser/...' }) - WebSocket 地址必须完整，不能只填
http://localhost:9222—— 后半段需从 Chrome 的http://localhost:9222/json页面里复制
调试时页面刷新后断点消失？webRoot 和 source map 是关键
即使配置全对，刷新后断点变灰，八成是 source map 没映射到源码。尤其 TypeScript 项目或 Webpack 构建的前端工程，路径错一点就全崩。
-
webRoot必须匹配实际源码位置，比如"${workspaceFolder}/src"而不是"${workspaceFolder}" - 确保构建产物里包含
.map文件，且sourceMappingURL指向正确路径 - 如果用
ts-node直接运行 TS 文件，需配sourceMap: true并启用inlineSourceMap
--remote-debugging-port 开没开、pwa-chrome 类型配没配、WebSocket 地址对不对、webRoot 和 source map 匹配不匹配——这四点漏一个，断点就卡在“看起来配好了，但就是不动”。
