Live Server没反应主因是缺失标准index.html或路径含非法字符；需确保工作区正确、文件名规范、端口未被拦截；非index入口须手动右键启动，端口冲突可强制指定。
Live Server插件为什么没反应？检查这三处
装了 Live Server 却点“Open with Live Server”没任何反应，大概率不是插件没装好，而是工作区根目录里压根没有 index.html 文件，或者文件名带空格/中文/特殊符号（比如 我的页面.html）。Live Server 默认只识别标准命名的入口文件，且对路径字符敏感。
常见卡点：
- 当前打开的是单个 HTML 文件，但 VSCode 没有以该文件所在文件夹为“工作区”——右键文件 → Reveal in Explorer，再右键文件夹 → Open Folder in Workspace
-
index.html存在，但被放在子文件夹（如src/index.html），此时需手动右键该文件 → Open with Live Server，不能依赖自动启动 - 系统启用了杀毒软件或防火墙，拦截了
localhost:5500这类本地端口，可临时禁用测试
如何指定非 index.html 的入口文件启动？
Live Server 不支持全局配置默认启动页，但可以通过项目级配置实现。在项目根目录新建 .vscode/settings.json（注意是 .vscode 文件夹），写入：
{
"liveServer.settings.donotShowInfoMsg": true,
"liveServer.settings.root": "./",
"liveServer.settings.CustomBrowser": "chrome"
}
关键在于：它本身不提供“默认打开 xxx.html”的选项；真正起作用的是你右键哪个文件 → Open with Live Server，它就以那个文件为根路径启动服务。所以想用 main.html，就直接右键它操作，而不是指望插件自动猜。
立即学习“前端免费学习笔记（深入）”；
补充说明：
- 如果项目结构是
/pages/login.html，右键该文件启动后，浏览器地址会是http://127.0.0.1:5500/pages/login.html，相对路径引用 JS/CSS 仍按文件系统层级解析 - 不建议用
liveServer.settings.AdvanceCustomBrowserCmdLine硬塞参数改启动页，容易和热重载冲突
CSS/JS 修改后不刷新？检查文件保存与服务器监听机制
Live Server 的“实时刷新”本质是：监听文件保存事件 + 注入一个 WebSocket 客户端脚本到 HTML 中。它不会扫描整个目录树，只监听你当前工作区中已打开的、且被修改并保存过的文件。
典型失效场景：
- 写了 CSS 但没按
Ctrl+S（或Cmd+S）保存——它不监听编辑过程，只响应保存动作 - HTML 里用
<link rel="stylesheet" href="style.css">，但实际文件叫style.min.css，404 导致样式不生效，你以为是没刷新，其实是路径错了 - 使用了构建工具（如 Vite、Webpack）又同时开了 Live Server，两个服务抢端口或注入逻辑冲突，浏览器控制台可能出现
WebSocket connection to 'ws://...' failed
验证是否监听生效：修改任意一个已打开的 HTML 文件并保存，看 VSCode 右下角是否弹出 “Reloading…” 提示。没有，说明监听链路断了。
端口被占用或想换端口怎么改？
Live Server 默认用 5500，但只要该端口被其他程序（如另一个 VSCode 窗口、Python 的 http.server、Docker 容器）占着，它会自动顺延到 5501、5502……直到找到空闲端口。这个行为不可关闭，但可以强制指定。
方法是在 .vscode/settings.json 中加一行：
{
"liveServer.settings.port": 8080
}
注意：
- 改完要重启 VSCode 或至少重新加载窗口（
Ctrl+Shift+P→ Developer: Reload Window）才生效 - 如果
8080已被占用，它不会报错也不会 fallback，而是直接启动失败——此时右下角会出现红色提示 “Unable to start Live Server”，得换端口号 - 浏览器访问时必须显式写端口，比如
http://127.0.0.1:8080/test.html，不能省略
真实项目里，端口冲突常发生在多前端项目并行开发时，建议团队约定每人用不同端口段（如 55xx、80xx、30xx），比反复查 kill 进程更省时间。
