VSCode远程开发不支持直接浏览器预览，因Live Server和Browser Preview均需本地GUI环境；正确做法是远程服务监听0.0.0.0并本地访问IP+端口。
VSCode 本身不支持“远程打开浏览器预览”——所谓“远程”，必须明确是“在远程机器上起服务，本地浏览器访问”，还是“在远程开发环境里启动本地浏览器”，二者技术路径完全不同，且后者根本不可行。
Live Server 在 SSH/WSL 远程环境中无法自动打开浏览器
当你通过 Remote-SSH 或 WSL 连接到 Linux 服务器时，Live Server 插件仍会尝试在远程系统上调用 x-www-browser 或 xdg-open，但远程服务器通常无图形界面，命令失败且无提示；VSCode 状态栏可能显示 Go Live，但浏览器完全不会弹出。
- 这不是插件 bug，而是设计限制：浏览器进程必须运行在有 GUI 的环境，而 SSH 终端或 WSL 默认无显示服务器（DISPLAY）
- 解决办法不是“让远程开浏览器”，而是把远程服务暴露给本地：确保远程服务监听
0.0.0.0:5500（而非默认的127.0.0.1:5500），再在本地浏览器手动访问http://[远程IP]:5500/xxx.html - 若使用 WSL2，需额外配置 Windows 防火墙放行端口，并在 WSL 中运行
sudo ufw allow 5500（如启用 ufw） - 更稳妥的方式是改用
liveServer.settings.port指定高位端口（如8080），避开公司网络常见拦截策略
Browser Preview 插件在远程连接中不可用
Browser Preview 插件依赖本地安装的 Chrome/Edge，并在 VSCode 后台启动一个 headless Chromium 实例；该实例必须与 VSCode 主进程同机运行。一旦你连入 Remote-SSH，插件实际运行在远程机器上，但远程没装 Chrome，也无权调用你的本地浏览器。
- 它不会报错，但点击“Open Preview”后预览窗口空白，开发者工具里能看到
net::ERR_CONNECTION_REFUSED - 不要尝试在远程服务器上安装 Chrome 并硬配
browser-preview.chromePath——WSL2 下 Chromium headless 支持有限，SSH 环境下几乎必然崩溃 - 如果你真需要内嵌预览，唯一可行路径是：本地 VSCode + 本地 Live Server + 本地浏览器，所有文件通过 Remote Explorer 同步到远程，开发流程保持“本地预览、远程部署”分离
file:// 协议在远程场景下彻底失效
有人试图用 View in Browser 类插件右键打开 HTML 文件，期望在远程连接中“直接看效果”。这只会生成类似 file:///home/user/project/index.html 的地址，粘贴到本地浏览器后 404 —— 因为本地浏览器根本读不到远程文件系统。
-
file://是纯客户端协议，不经过网络，也不走任何服务端逻辑 - 远程路径对本地浏览器毫无意义；哪怕你手动把整个项目 scp 下来，路径结构也大概率不同
- 任何依赖
fetch、import()、localStorage（部分浏览器限制）的现代前端代码，在file://下都会静默失败，控制台报错但页面看起来“好像能动” - 正确做法永远是：用
Live Server起 HTTP 服务，再通过 IP + 端口访问，哪怕只是本机http://localhost:5500
真正容易被忽略的一点：VSCode 的 Remote 开发模式下，所有扩展行为都以远程环境为准。你以为在“本地写代码”，其实编辑器后台的 Node.js 进程、插件生命周期、文件监听器，全跑在远程。浏览器预览这件事，从来就不是“VSCode 控制浏览器”，而是“VSCode 启动服务 → 浏览器主动请求 → 双方协商资源加载”。漏掉其中任一环，预览就断在半路。
