browser preview插件已失效，因其调试类型被移除；稳定预览需绑定编辑器生命周期并避免跨进程抖动，推荐vs browser（内嵌chromium）或live server+open in browser组合。
VSCode 里浏览器预览不稳定，根本原因不是“插件不够多”，而是多个插件争抢同一控制权，或依赖外部浏览器进程导致状态不可控。真正稳定的预览，必须满足两个条件：一是预览环境与编辑器生命周期绑定，二是避免跨进程通信抖动。
Browser Preview 插件已失效，别再配置 browser-preview 类型的 launch.json
截至 2026 年中，browser-preview 调试类型在官方 Debugger for Chrome 扩展中已被移除，继续保留如下配置会导致调试启动失败或静默无响应：
{
"type": "browser-preview",
"request": "launch",
"name": "Browser Preview: Launch",
"url": "http://localhost:3000"
}
常见错误现象包括：Cannot find debug adapter for type 'browser-preview'，或点击运行后无任何窗口弹出。替代方案只有两个明确路径：
- 改用 VS Browser（推荐）：它内嵌 Chromium，不依赖系统 Chrome 安装路径，进程由 VSCode 统一托管，崩溃时自动重启渲染进程
- 退回轻量组合：用
Live Server+ 手动聚焦浏览器标签页，配合Open in Browser快速唤起，规避调试协议层问题
VS Browser 插件的稳定性关键配置项
VS Browser 不是“装了就稳”，它的稳定性高度依赖三项配置是否关闭默认陷阱：
- 禁用
vsbrowser.enableDevTools：开启后每次预览都会加载完整 DevTools 面板，内存占用翻倍且易触发 Electron 渲染进程 OOM - 设置
vsbrowser.defaultUrl为本地静态路径（如file:///path/to/index.html），而非http://localhost:3000；后者需额外维持 HTTP 服务，任一环节断开即白屏 - 关闭
vsbrowser.autoReloadOnSave，改用项目级热更机制（如 Vite/HMR）；VS Browser 自身的 reload 是全页面刷新，会丢失断点和 console 上下文
这些配置在 settings.json 中显式声明，比默认值更能抑制偶发性白屏或卡死。
为什么 Live Server + Open in Browser 组合反而更稳？
这套组合绕开了所有调试协议和嵌入式浏览器的复杂性，本质是“最小可行预览”：
-
Live Server启动的是一个极简 Node.js HTTP 服务，无 UI、无渲染、纯文本响应，崩溃概率趋近于零 -
Open in Browser只做一件事：调用系统默认浏览器打开指定 URL，不接管页面生命周期，不注入脚本，不监听 network - 当你要查样式时，直接用
CSS Peek定位定义，再切到浏览器按F12检查——分工明确，故障域隔离
这种解耦方式在低配机器、CI 环境、或需要长期驻留预览页的场景下，稳定性远超任何“一体化”插件。
真正的稳定，不是让一个插件扛下所有事，而是把“预览”这件事拆成可独立验证、可单独重启的环节。VS Browser 适合需要内联调试的场景，Live Server + Open in Browser 适合追求确定性的日常开发——选哪个，取决于你当前最不能容忍哪类中断。
