Atom本身不运行HTML，它只是文本编辑器；所谓“运行”需通过浏览器加载，而正确加载取决于协议、路径和服务——双击打开或右键“Open in Browser”走file://协议，会触发CORS、路径解析失败等问题；atom-live-server插件需重启Atom才生效，且以当前HTML文件所在目录为根启动HTTP服务（如http://localhost:3000），仅监听<link>和<script>直接引用的文件变更；命令行npx live-server --port=8080更可靠，根路径明确、端口可控、错误直出终端、支持全目录热重载。
atom-live-server 按 Ctrl+Alt+L 没反应？检查这三件事
这不是插件坏了，而是启动条件没满足：
- 必须先关闭 Atom，终端执行
apm install atom-live-server，再重启 Atom —— 不重启插件根本不会加载 - 快捷键
Ctrl+Alt+L（Windows/Linux）或Cmd+Alt+L（macOS）只在已打开一个.html文件时才生效；如果当前是空白标签页或 JS 文件，按键无效 - 插件以「当前打开的 HTML 文件所在目录」为根路径起服务，不是项目根目录。比如你打开的是
src/index.html，那它只会监听src/及其子目录下的变更，assets/style.css改了也不会刷新
为什么改了 CSS/JS 但浏览器没刷新？
atom-live-server 的刷新触发机制很窄，只响应以下两类变更：
-
<link rel="stylesheet">和<script src="...">标签中直接引用的文件（路径必须能被浏览器通过 HTTP 正确请求到） - 当前 HTML 文件自身内容变化
- 它不监听
@import的 CSS、不递归解析import的 JS 模块、也不管data-src或动态插入的资源
常见踩坑：CSS 放在 assets/css/，但 HTML 在根目录，<link href="assets/css/style.css"> 能加载，可一旦你把 HTML 移到 src/ 下，路径就变成相对 src/ 的，assets/ 就 404 了 —— 刷新失败不是插件问题，是路径失效。
atom-html-preview 和 live-server 能共存吗？
不能。它们都会尝试监听端口（默认都是 3000），且底层逻辑冲突：
立即学习“前端免费学习笔记（深入）”；
-
atom-html-preview是纯静态解析，走file://协议，在 Atom 内部渲染，不支持fetch()、import、Service Worker -
atom-live-server是真实 HTTP 服务，依赖http://localhost:3000，支持所有 Web API - 两者同时启用，浏览器大概率卡在
Connecting…，控制台报ERR_CONNECTION_REFUSED或白屏
解决方法：禁用 atom-html-preview，只保留 atom-live-server；或者干脆不用插件，改用命令行起服务（更稳、端口可控、错误直出终端）。
npx live-server --port=8080 比插件强在哪？
命令行方式绕开了 Atom 插件生态的所有不确定性：
- 端口明确可控：
--port=8080避开 3000 冲突，无需猜它顺延到了 3001 还是 3002 - 根路径确定：
npx live-server默认以当前终端所在目录为根，和你项目结构对得上 - 错误即时可见：端口被占、路径 404、MIME 类型错，全打在终端里，不用翻 Atom 控制台
- 热重载更可靠：它监听整个目录树，包括
assets/、src/、public/，改任意层级的静态资源都会触发刷新
唯一要注意的是：Atom 内置终端按 Ctrl + ` 打开后，要先 cd 到项目根目录再执行命令，否则服务根路径就错了 —— 这点比插件还容易忽略。
atom-html-preview、关掉 open-in-browser，终端里一行 npx live-server --port=8080，然后专注写代码。 
