根本原因是file://协议下浏览器无法获取HTTP响应头，导致Content-Type缺失、编码误判及外部资源路径失效；需确保meta charset在head最前、文件UTF-8无BOM、资源路径正确或转内联/数据URL。
直接双击打开本地保存的HTML文件出现格式错乱，根本原因不是代码写错了，而是浏览器在 file:// 协议下丢失了关键上下文——它既看不到HTTP响应头里的 Content-Type，也容易忽略或误判文件编码和外部资源路径。
为什么“网页，完整”比“仅HTML”更可靠
用浏览器“另存为”时选“仅HTML”，会剥离所有图片、CSS、JS，只保留内联样式和文字结构；而“网页，完整”会生成一个HTML文件 + 同名文件夹（含所有资源），路径引用保持原样。但注意：file:// 协议下相对路径仍可能失效（比如CSS里 url(../images/bg.png) 在本地文件夹结构变动后就404）。
- “仅HTML”适合纯文本快照，不依赖样式和图片
- “网页，完整”适合归档浏览，但必须保证HTML文件与资源文件夹同级且不重命名
- 若需移动或分享，优先转成
.mhtml（单文件封装），但要注意：手动另存为的.mhtml常因CSS路径未重写而显示异常
meta charset="UTF-8" 必须出现在 <head> 最前面
很多编辑器导出HTML时把 <meta charset="UTF-8"> 插在 <title> 后面，甚至混在注释里。浏览器在 file:// 下解析时，若前几百字节没看到明确的UTF-8声明，可能按系统默认编码（如Windows的GBK）解码，导致中文全乱。
- 打开HTML文件，确认
<meta charset="UTF-8">是<head>内第一个标签（紧贴<head>开始，前面不能有空格、BOM、注释） - 用VS Code或Notepad++检查右下角状态栏：显示编码必须是
UTF-8，不是UTF-8 with BOM或GBK - 如果编辑器显示
GBK，别直接改meta标签——先用“另存为 → UTF-8”转换文件本身编码，再保存
CSS/JS外部文件路径在本地容易失效
线上网页的CSS常通过CDN或绝对路径引入，如 <link href="https://cdn.example.com/style.css">，这类链接在本地双击打开时仍可加载；但如果是相对路径 <link href="css/main.css">，就必须确保该CSS文件真实存在于对应子目录中。
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具（F12）→ Network 标签页，刷新页面，看哪些CSS/JS请求状态是
failed或net::ERR_FILE_NOT_FOUND - 若路径错误，可临时改为内联：把CSS内容复制进
<style></style>，JS内容复制进<script></script>，验证是否恢复样式 - 更稳妥的做法是把所有外部资源转为Data URL（适合小图/CSS），或统一用
base标签修正根路径：<base href="file:///C:/path/to/folder/">（注意斜杠方向和本地盘符）
保存为 .mhtml 后显示异常，重点查CSS块位置
手动将“网页，完整”另存为 .mhtml 时，浏览器不会自动重写CSS中的资源引用，导致MHTML内部的CSS仍指向旧路径，从而样式丢失。真正的“在线保存为MHTML”能正确嵌入并关联所有资源。
- 用记事本打开异常的
.mhtml文件，搜索Content-Type: text/css - 找到对应的CSS内容块，对比正常MHTML中同一位置的
Content-Location和实际CSS内容 - 把正常MHTML里那段CSS完整复制过来，替换掉异常文件中对应块（注意保留
------MultipartBoundary--分隔线结构） - 保存后重新打开，样式通常立即恢复——本质是修复了MHTML内部CSS与HTML主体的绑定关系
最易被忽略的一点：哪怕所有标签、编码、路径都对了，只要HTML文件开头存在不可见字符（比如BOM、零宽空格），浏览器在 file:// 下就可能跳过第一行解析，导致 meta charset 失效。务必用支持二进制查看的编辑器确认文件开头三个字节是 EF BB BF（UTF-8 BOM）或干脆无BOM——后者更安全。
