Atom预览HTML需分清file://与http://协议：atom-html-preview内嵌渲染但不支持fetch等API；atom-live-server启本地服务实现保存即刷新，须用http://访问；open-in-browser仅手动打开，最轻量。
Atom 本身不运行 HTML，也不渲染页面——它只是个文本编辑器。想看到效果，必须把 HTML 文件交给浏览器处理。实时预览的关键不在 Atom，而在「怎么让浏览器及时加载最新改动」。
atom-html-preview 插件：编辑器内嵌预览，带样式但不走 HTTP
这个插件在 Atom 右侧开一个独立面板，直接解析当前 .html 文件并渲染，支持内联 CSS、<style> 和外部 <link rel="stylesheet">（包括 CDN），但不走 HTTP 协议，因此：
- 不支持
fetch()、XMLHttpRequest等跨域或协议敏感操作 - 无法测试 Service Worker、WebSockets 或任何依赖
http://的 API - 路径引用必须是相对路径且位于当前文件可访问范围内；
../assets/style.css行，/assets/style.css不行 - 快捷键默认是
Ctrl+Shift+H（Windows/Linux）或Cmd+Shift+H（macOS），若冲突可在Keymap中自定义为Ctrl+F12等 - 安装后无需重启 Atom，但必须确保文件语法识别为 HTML（右下角状态栏显示
HTML）
atom-live-server 插件：真正自动刷新，但必须用 http:// 打开
它起一个本地最小 HTTP 服务（默认端口 3000），监听文件变化后调用 location.reload()。这是唯一能实现「保存即刷新」的方案，但有硬性前提：
- 不能双击打开
file://地址，必须用插件启动后浏览器跳转到类似http://localhost:3000/index.html的地址 - 只监听「当前打开的 HTML 文件所在目录及其子目录」；若
index.html在/project/src/，而style.css在/project/assets/，则改 CSS 不会触发刷新 - 不响应
@import的 CSS 文件变更，只认<link>和<script>标签引入的资源 - 端口被占时会顺延（如
3001），但无提示——如果没反应，先检查控制台是否报ERR_CONNECTION_REFUSED - 快捷键是
Ctrl+Alt+L（Windows/Linux）或Cmd+Alt+L（macOS），启动前需确认 Atom 已关闭再执行apm install atom-live-server
open-in-browser 插件：最轻量的“手动刷新”方案
它不监听、不启服务，只做一件事：把当前 HTML 文件用默认浏览器打开。适合写完一整块再看效果的节奏：
立即学习“前端免费学习笔记（深入）”；
- 快捷键默认
Ctrl+Alt+O（Windows/Linux）或Cmd+Alt+O（macOS），可改 - 安装后必须重启 Atom，否则菜单项灰色不可用
- 右键菜单中 “Open in Default Browser” 有时不出现，是因为文件未保存或扩展名不是
.html - 不解决刷新问题，每次改完仍要手动按
F5或Cmd+R - 比
atom-html-preview更少出兼容问题，尤其对含base href或动态路由的单页应用更友好
为什么改了 CSS/JS 但预览没变？常见路径和协议陷阱
绝大多数「没刷新」问题，根源不是插件失效，而是浏览器根本没拿到新资源：
- 用
atom-html-preview时，检查浏览器开发者工具的Network面板——如果有404请求，说明<link href="css/style.css">中的路径相对于当前 HTML 文件错了 - 用
atom-live-server时，打开控制台看是否有GET http://localhost:3000/xxx.js 404，这表示文件不在监听路径内，得移动文件或调整引用 - 所有插件都不处理
file://协议下的跨文件请求（比如 JS 里fetch('./data.json')），必须走http:// - Atom 自带的
Ctrl+Shift+M原生预览只用于 Markdown，对 HTML 文件无效，误按也不会出错，但也没效果
真正卡住人的往往不是装哪个插件，而是搞不清「当前预览走的是 file:// 还是 http://」、「资源路径是相对于谁」、「插件到底监听了哪些目录」。盯住浏览器地址栏和 Network 面板，比重装插件有用得多。
