Live Server启动后页面没刷新，需检查三件事：一是右键菜单是否出现“Open with Live Server”，确保文件已保存且焦点在HTML标签页；二是地址栏是否为http://127.0.0.1:5500/而非file:///；三是CSS/JS路径是否相对于当前HTML文件位置，避免404或缓存导致样式未更新。
Live Server 启动后页面没刷新？检查这三件事
Live Server 不是“装完就自动生效”的魔法，它只对当前右键打开的 index.html 及其直接引用的资源生效。常见失效场景不是插件坏了，而是路径或触发方式不对：
- 右键菜单里没出现
Open with Live Server→ 确保文件已保存（Ctrl+S），且编辑器焦点在该 HTML 标签页上，不是空标签或 JSON 文件 - 地址栏仍是
file:///开头 → 说明根本没走 Live Server，而是用了系统默认打开方式；必须看到http://127.0.0.1:5500/或类似本地端口才算成功启动 - 改了
style.css但样式没变 → 检查 HTML 中<link rel="stylesheet" href="style.css">的路径是否相对于该 HTML 文件位置，不是工作区根目录；也可能是浏览器缓存，用Ctrl+Shift+R强制重载
想让 Chrome 成为默认浏览器？别只改系统设置
VSCode 的 Live Server 插件不读取系统默认浏览器，它依赖插件自身的配置项。Windows/macOS 上双击 Chrome 图标启动的实例，默认不开放调试协议，VSCode 无法接管。
- 必须在 VSCode 设置中搜
liveServer.settings.CustomBrowser，填入chrome（小写，不能写 Chrome 或 Google Chrome） - 如果要用 Debugger for Chrome 调试 JS，还需手动启动 Chrome 并带参数：
chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug（macOS/Linux）或"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir=C:\temp\chrome-debug（Windows） - 多个 Chrome 实例共存时，端口可能被占，此时要同步改
launch.json里的port字段，比如改成9223
断点打不中？webRoot 和 url 必须严格匹配项目结构
Debugger for Chrome 的断点失效，90% 是因为 webRoot 指向错误。它不是“你代码放在哪”，而是“浏览器实际加载的 HTML 文件从哪个目录起算相对路径”。
- 纯静态 HTML 项目：
url填http://127.0.0.1:5500/index.html（Live Server 默认端口），webRoot填"${workspaceFolder}" - Vite 项目：
url填http://localhost:5173/，webRoot仍为"${workspaceFolder}"，但必须确保vite.config.ts中build.sourcemap设为true - Webpack Dev Server：
webRoot应指向源码目录（如"${workspaceFolder}/src"），不是dist输出目录，否则断点会打在压缩后的 bundle.js 上
实时修改 CSS/JS 但页面没反应？和 Live Server 无关
Live Server 只负责刷新页面，它不处理热更新（HMR）。如果你改了 JS 逻辑但状态没更新、DOM 没重绘，问题不在 Live Server，而在运行时环境本身。
- React/Vue/Svelte 项目：这些框架自带 HMR，但前提是它们自己的 dev server 在运行（如
vite dev或npm run serve），不是靠 Live Server 启动的 - 纯 JS 逻辑变更没生效：检查控制台是否有语法错误阻断执行；确认
script标签没加defer或type="module"导致执行时机变化 - CSS 修改无效：除了缓存，还要注意 CSS 优先级是否被其他规则覆盖，Live Server 刷新后样式表已重新加载，但渲染结果取决于层叠顺序，不是加载失败
webRoot 的路径映射——这两处错一点，断点就永远打不中，而现象看起来就像“插件没用”。 
