VSCode本身不直接调试浏览器，完全依赖插件打通CDP协议：通过启动带--remote-debugging-port参数的Chrome实例，再以WebSocket连接该端口收发JSON-RPC消息；launch.json中"type": "chrome"实际调用的是插件注册的Debug Adapter（如pwa-chrome），由插件负责启停浏览器、转发断点与事件。
VSCode本身不直接调试浏览器，靠插件打通CDP协议
VSCode编辑器内核不内置浏览器引擎，也没法直接解析HTML或执行DOM操作。它真正能“调试浏览器”，全靠插件实现底层通信——核心是Chrome DevTools Protocol（CDP）。比如Debugger for Chrome和vscode-browser-preview，都通过启动带--remote-debugging-port参数的Chrome实例，再用WebSocket连接该端口，收发JSON-RPC消息。没插件，VSCode连浏览器进程都发现不了。
launch.json里type: "chrome"实际调用的是插件提供的adapter
你在launch.json里写"type": "chrome"，VSCode不会自己去跑Chrome；它只是根据这个字段，去找已安装插件注册的Debug Adapter。比如Debugger for Chrome插件在激活时，会向VSCode注册adapterID为"pwa-chrome"的适配器。一旦配置匹配，VSCode就把调试请求转发过去，由插件负责启停浏览器、注入脚本、转发断点事件。
- 如果插件没装或禁用，
type: "chrome"会报错：Cannot find debug adapter for type 'chrome' -
vscode-js-debug后来统一接管了大部分JS调试场景，但依然依赖插件提供CDP连接能力 -
browser-preview走的是类似路径：启动浏览器 → 创建CDPSession→ 监听Page.loadEventFired等事件
插件决定你能看到什么、在哪打断点
浏览器调试体验的颗粒度，完全取决于插件对CDP能力的封装程度。比如：
- 是否支持
sourceMapPathOverrides映射压缩JS到源码？取决于插件解析Source Map的逻辑 - 能否在
fetch发起前停住？要看插件是否监听Network.requestWillBeSent事件并暴露为断点类型 - 右键“Reveal in Edge”跳转到VSCode文件？这是插件把CDP返回的
resourceId和本地路径做了映射 -
Console Ninja能把console.log输出直接塞进编辑器底部面板——它不是读终端日志，而是通过CDP的Runtime.consoleAPICalled事件实时捕获
插件失效时，整个调试链就断在第一步
常见症状不是“断点不触发”，而是根本进不了调试状态：
- 启动后Chrome一闪而过，VSCode显示
Unable to launch browser: timeout→ 插件没成功建立CDP连接 - 断点灰色不可用，提示
Breakpoint ignored because generated code not found→ 插件的Source Map解析失败或路径映射错 - 控制台输出没出现在VSCode里，但浏览器DevTools里有 →
Console Ninja没收到Runtime.consoleAPICalled事件，可能是CDP会话未启用或权限被拦截
这些都不是VSCode的问题，而是插件与CDP之间的握手细节出了偏差——比如Chrome版本升级后移除了某个CDP命令，插件没及时适配，就会静默失败。
