html乱码主因是文件实际编码非utf-8且file://协议无http响应头，需用编辑器另存为utf-8无bom，并将meta charset放head最顶部，或启用live server本地服务器。
HTML 文件保存编码不对
win10 默认记事本用的是 ANSI（实际是 GBK），你双击打开一个含中文的 HTML，哪怕写了 <meta charset="UTF-8">，浏览器也大概率显示乱码——因为文件本身根本不是 UTF-8 编码。
- 用记事本打开后，点「另存为」，右下角编码选项必须选
UTF-8（不是「UTF-8-BOM」，BOM 会多出三个隐藏字节，某些老环境反而更糟） - VS Code 用户注意：右下角状态栏点编码名 → 选
Save with Encoding→UTF-8；别只点「Reopen with Encoding」，那只是临时换视角，没改文件本身 - Notepad++ 用户：菜单栏「编码」→「转为 UTF-8 无 BOM 编码」→ 再「保存」；如果已乱码，先「编码」→「以 ANSI 编码打开」，再转 UTF-8 保存
浏览器直接双击打开 file:// 协议页面
win10 下双击 HTML 文件，浏览器走的是 file:// 协议，不经过服务器，HTTP 响应头完全缺失。此时浏览器只能靠 <meta charset> 和文件 BOM 推断编码——而这两者都容易失效。
- 强制让浏览器信任 meta：把
<meta charset="UTF-8">放在最顶部，前面不能有任何字符（包括空格、注释、BOM） - 别依赖「自动编码检测」：chrome/firefox 的自动识别在本地文件里经常误判为 GBK，手动在地址栏输入
javascript:document.charset='UTF-8'可临时修复（仅调试） - 真正靠谱的做法：用本地服务器跑，比如 VS Code 安装
Live Server插件，右键「Open with Live Server」——它会起一个http://127.0.0.1服务，自动带Content-Type: text/html; charset=utf-8响应头
windows 系统区域设置干扰
Win10 控制面板里的「区域」设置会影响老旧 API 和部分 IE 内核渲染逻辑，尤其当 HTML 没写 meta 或用了过时的 <meta http-equiv="Content-Type"> 时，系统会强行 fallback 到当前 ANSI 代码页（通常是 GBK）。
- 检查路径：控制面板 →「时钟和区域」→「区域」→「管理」选项卡 →「更改系统区域设置」→ 确认勾选了「Beta 版：使用 Unicode UTF-8 提供全球语言支持」（Win10 1903+ 可用）
- 不勾选也没关系，但务必避免把「非 Unicode 程序的语言」设成「中文（简体，中国）」以外的其他语言，否则记事本等工具读写文件会默认用对应代码页
- 这个设置不影响现代浏览器主渲染逻辑，但会影响 Node.js
fs.readFile()读取未声明编码的文件、或某些 Python 脚本处理 HTML 的行为
外部资源（CSS/JS）偷偷搞破坏
一个 HTML 页面显示正常，但引入的 style.css 或 main.js 里有中文注释或字符串，且它们是 GBK 编码保存的，浏览器加载时就会污染整个页面的编码上下文，导致后续 dom 解析错乱。
立即学习“前端免费学习笔记（深入）”；
- 检查所有
<link rel="stylesheet">和<script src></script>引入的文件，用 VS Code 或 Notepad++ 打开，确认右下角显示的是UTF-8 - CSS 文件里不要写
@charset "GBK";这种过时声明；JS 文件同理，避免// @encoding GBK类注释 - 如果必须兼容旧资源，可在
<link>标签里加charset="UTF-8"属性（虽已废弃但部分浏览器仍识别）：<link rel="stylesheet" href="a.css" charset="UTF-8">
Win10 下 HTML 乱码最常卡在「文件真实编码」和「file:// 协议无响应头」这两个地方，其他都是连锁反应。改完记得清浏览器缓存，别信「刷新一下就好」——浏览器可能已经把错误编码的版本缓存进磁盘了。