vscode-browser-preview能替代手动开浏览器，但需基于headless chromium启动独立渲染进程，确保dom/cssom/js环境与真实chrome一致，不支持扩展、用户登录态及service worker（除非显式启用）。
VSCode 插件本身不直接参与浏览器运行时行为，它只在编辑器侧提供辅助能力；真正影响浏览器开发体验的，是那些能桥接编辑器与浏览器运行环境的插件——比如 vscode-browser-preview、Debugger for Chrome、Live Server。它们解决的不是“写代码”问题，而是“改完代码后怎么立刻看到效果+查清楚为什么没效果”这个闭环。
vscode-browser-preview 能替代手动开浏览器吗？
能，但有前提：它不是简单地打开一个 iframe，而是基于 Headless Chromium 启动独立渲染进程，所以 DOM、CSSOM、JS 执行环境和真实 Chrome 一致。但它不支持扩展、不加载用户配置的书签或登录态，也不运行后台 service worker（除非你显式启用）。实际使用中要注意：
- 预览窗口无法访问
localhost以外的跨域资源，除非服务端已配 CORS 或你用http-server -p 8080 -c-1启动无缓存服务 - 右键菜单里的“Open in Browser”是调系统默认浏览器，和
vscode-browser-preview无关，别混淆 - 截图导出默认是 PNG，若页面含大量半透明图层，可能发灰——此时要在插件设置里把
browserPreview.imageFormat改成jpeg
Debugger for Chrome 的 launch.json 配置为什么总连不上？
90% 的失败源于 webRoot 路径没对齐源码位置，或者目标 URL 根本没跑起来。比如你用 Vite 启动项目，默认地址是 http://localhost:5173，但 launch.json 里写的是 http://localhost:3000，VSCode 就会卡在“正在启动浏览器”不动。
更隐蔽的问题是构建产物路径映射：TypeScript 或 Vue SFC 编译后，浏览器实际执行的是 dist/assets/index.xxxx.js，但断点打在 src/App.vue 上——这时必须加 sourceMapPathOverrides：
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome",
"url": "http://localhost:5173",
"webRoot": "${workspaceFolder}/src",
"sourceMapPathOverrides": {
"webpack:///src/*": "${webRoot}/*"
}
}
注意 webpack:/// 前缀来自 sourcemap，Vite 项目要换成 vite:///，否则断点永远不命中。
Live Server 和 vscode-browser-preview 能一起用吗？
可以，但没必要叠加。Live Server 是轻量级 HTTP 服务 + 自动刷新，适合纯 HTML/CSS/JS 原生项目；vscode-browser-preview 自带内建服务（仅限单文件），也支持代理到外部服务（通过 browserPreview.startUrl 配置）。两者同时启用会导致两个服务监听同一端口，报错 EADDRINUSE。
推荐策略：
- 静态页面 → 用 Live Server，开
http://127.0.0.1:5500，右键“Open with Live Server” - 现代框架项目（Vue/React/Vite）→ 关掉 Live Server，用
vscode-browser-preview并配置startUrl指向本地 dev server - 需要调试 network tab 或 performance 面板 → 必须用
Debugger for Chrome，因为vscode-browser-preview的 DevTools 是阉割版，不显示 Security 或 Application 标签页
最常被忽略的一点：所有这些插件都依赖 VSCode 的 node 运行时环境。如果你在 WSL 或远程 SSH 环境中开发，插件实际运行在远端，但浏览器预览和调试必须走本地 GUI —— 这时候得确认 VSCode Remote 的 X11 转发或 Windows Subsystem for Linux 的 GUI 支持是否开启，否则预览窗口根本弹不出来。
