live server点「go live」只显示端口不打开浏览器，本质是系统级浏览器启动失败；需检查liveserver.settings.nobrowser是否为true、custombrowser路径格式是否正确、系统http协议关联是否被劫持，且务必以右下角状态栏显示的实际url为准。
Live Server 点「Go Live」只显示端口不打开浏览器
这是最常见现象，本质是插件没触发系统级浏览器启动，而非服务没跑起来。右下角看到 http://127.0.0.1:5500 就说明服务已就绪，问题出在“打开”这一步。
先检查设置里是否误启了禁用项：liveServer.settings.NoBrowser 如果值为 true，浏览器完全不会启动；删掉这一行或设为 false 即可。
- Windows 用户常被国产软件（如 QQ、迅雷）静默劫持
http协议注册，导致start https://example.com命令失效 —— 可在 CMD 里手动执行该命令验证 - macOS 上用
brew install --cask firefox安装的 Firefox，可能未正确注册为默认浏览器，open会 fallback 到 Safari；若 Safari 被禁用或损坏，就静默失败 - Linux 用户重点查
xdg-open是否可用，某些最小化安装系统甚至没装这个命令
Live Server 设置了 CustomBrowser 但浏览器仍打不开
填绝对路径看似直接，但路径格式和系统机制容易踩坑。VS Code 不校验路径是否存在，错一个字符或斜杠就静默失败。
Windows 示例："C:\Program Files\Mozilla Firefox\firefox.exe" —— 注意双反斜杠，且整个路径必须用英文引号包裹（空格不能省）
macOS 示例：/Applications/Google Chrome.app —— 必须指向 app bundle 根目录，不是二进制文件路径（比如 /Applications/Google Chrome.app/Contents/MacOS/Chrome 通常失败）
- 路径中含中文或特殊符号（如括号、&）极易出问题，建议换到纯英文路径
- 不要填浏览器的用户数据目录（如
~/Library/Application Support/Google/Chrome），那是配置路径，不是可执行入口 - 如果填了路径仍无效，先在终端用同样路径加 URL 测试：
"/Applications/Google Chrome.app" https://example.com
浏览器报 ERR_CONNECTION_REFUSED 或 “未发送任何数据”
这不是浏览器问题，是 Live Server 启动的服务不可达。状态栏显示的端口（如 5500）可能已被其他进程占用，但插件自动 fallback 到 5501，而你手动访问的还是旧端口。
务必以右下角状态栏显示的实际地址为准，不要硬敲 5500。
- 检查是否有另一个 VS Code 窗口、Python 的
http.server、Docker 容器或 Electron 应用占用了目标端口 - 勾选
liveServer.settings.UseLocalIp可解决部分内网环境（如公司防火墙、虚拟机桥接）下 localhost 不可达的问题 - 如果服务压根没起来，看 VS Code 输出面板里
Live Server标签页是否有错误日志，常见是当前目录含非法字符或权限不足
右键菜单根本没有 “Open with Live Server” 选项
插件不会对所有文件生效，它依赖两个条件：文件后缀匹配 + VS Code 当前语言模式识别为支持类型。
右下角点击语言模式（如显示 “Plain Text”），手动切到 HTML，菜单立刻出现 —— 这比改文件后缀更快捷。
- 默认只响应
.html和.htm，想支持.vue或.svelte，需在settings.json中加："liveServer.settings.FileExtension": {"vue": "html", "svelte": "html"} - 文件无后缀或后缀名被误判（如
index被识别为 Shell 脚本），菜单一定不出现 - 确认插件已启用：在扩展面板搜
Live Server，作者是ritwickdey，禁用状态图标会变灰
真正卡住的点往往不在 VS Code 插件本身，而在系统级协议关联、环境变量 PATH 缺失（尤其 Windows 下漏了 C:WindowsSystem32）、或代码里藏了个无限循环把浏览器拖垮 —— 后者不会报错，只让页面白屏或崩溃，容易误判为环境问题。
