必须确保文件实际编码、meta charset声明、HTTP响应头三者均为UTF-8且无BOM干扰；VS Code右下角显示“UTF-8”不等于文件真实为UTF-8，需用file -i或Reopen with Encoding验证，BOM和meta位置错误均会导致浏览器回退至GBK等默认编码而乱码。
meta charset 写对了，文件本身不是 UTF-8，照样乱码；反过来，文件是 UTF-8，但 meta charset 没写或写错位置，浏览器也认不出来。关键不在“写了没”，而在“写得准不准、存得对不对、传得稳不稳”。
确认编辑器当前显示的编码是否真实反映文件内容
VS Code 右下角显示 “UTF-8”，不代表文件真是 UTF-8；它可能只是“猜对了”，也可能“猜错了但没报错”。尤其 Windows 下用记事本保存过、从邮件附件拖进来的 HTML，常被误标为 UTF-8，实则 GBK。
- 在 VS Code 中按
Ctrl+Shift+P→ 输入 “Reopen with Encoding” → 选GBK或GB2312，看中文是否突然正常——如果能，说明文件实际是 GBK 编码 - Sublime Text：菜单
File → Reopen with Encoding → GB2312同理验证 - Linux/macOS 终端执行：
file -i yourfile.html，若输出charset=gbk或charset=us-ascii（实为 GBK 检测失败），就别信编辑器右下角了
强制保存为无 BOM 的 UTF-8
BOM（EF BB BF）在 HTML 开头会干扰 meta charset 解析——浏览器只扫描前 1024 字节找 meta，BOM 占了头三个字节，后面哪怕紧跟着 <meta charset="UTF-8">，也可能因偏移或解析逻辑被跳过。
- VS Code：按
Ctrl+Shift+P→ “Save with Encoding” → 选UTF-8（注意不是 “UTF-8 with BOM”） - Notepad++：菜单
编码 → 转为 UTF-8 无 BOM 格式 - 验证是否真去 BOM：终端运行
head -c 3 yourfile.html | xxd，输出不含ef bb bf才算成功
检查 meta charset 是否在 <head> 最前面且无干扰
它必须是 <head> 内第一个标签（或紧跟在 <head> 开始后、任何空白/注释/BOM 之前）。哪怕前面有个空格、换行、HTML 注释 <!-- -->，都可能导致浏览器 fallback 到系统默认编码（Windows 是 GBK）。
立即学习“前端免费学习笔记（深入）”；
- 正确写法（开头即生效）：
<head> <meta charset="UTF-8"> <title>页面标题</title> </head>
- 错误写法（带空格或注释）：
<head> <p><!-- 页面编码声明 --> <meta charset="UTF-8">
—— 这种会被跳过 - 不要写成
<meta charset="utf8">或<meta charset="UTF8">，只有"UTF-8"是标准值，大小写敏感
避免本地双击打开时的协议陷阱
直接双击 HTML 文件走的是 file:// 协议，此时 HTTP 响应头完全失效，浏览器只依赖 meta charset 和文件 BOM。一旦它没起作用，就立刻 fallback 到系统编码（Windows 默认 GBK），乱码几乎必然发生。
- 开发阶段务必用本地服务器预览：VS Code 安装 Live Server 插件，右键 → “Open with Live Server”
- 或者命令行启动简易服务：
npx http-server（需提前npm install -g http-server） - 此时地址是
http://127.0.0.1:8080/xxx.html，HTTP 响应头Content-Type: text/html; charset=utf-8与meta形成双重保障
真正容易被忽略的，是“文件内容编码”和“编辑器声称编码”长期不一致带来的惯性误判——你改了十次 meta，却没查过文件自己到底是什么编码。先验真，再修形。
