确认文件真实编码非UTF-8：VS Code用“Reopen with Encoding”试GBK，Sublime同理；Linux/macOS执行file -i，若显示charset=gbk或us-ascii即非UTF-8；右下角显示不可信，需实测验证。
乱码不是浏览器问题，是编码链断在了某一处：文件存错、声明写错、传输压错，三者缺一不可。
怎么确认文件真实编码不是UTF-8？
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检测失败），就别信编辑器右下角了
为什么写了也无效？
浏览器只扫描HTML前1024字节找meta charset，且必须在<head>开始后紧贴着出现。BOM、空格、注释、甚至换行，都会让它失效。
- BOM（
EF BB BF）占头3字节，会把<meta charset="UTF-8">往后推，导致浏览器跳过识别 - 错误写法示例：
<head>\n <!-- 编码声明 -->\n <meta charset="UTF-8">—— 注释在前，直接失效 - 正确位置：
<head><meta charset="UTF-8"><title>，中间不能有任何字符（包括空格和换行） - 别写
utf8或UTF8，只有"UTF-8"是标准值，大小写敏感
本地双击打开（file://）时乱码怎么办？
file://协议下没有HTTP响应头，浏览器完全依赖文件内容本身：BOM + meta charset必须同时成立，少一个就fallback到系统默认编码（Windows是GBK）。
立即学习“前端免费学习笔记（深入）”；
- 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 http-equiv="Content-Type" content="text/html; charset=UTF-8">——HTML5已不推荐，且在file://下更不可靠
HTTP服务下还乱码，该查哪？
走http://或https://时，服务器返回的Content-Type响应头优先级高于meta charset。如果头里写着charset=gbk，哪怕meta写对了也会被覆盖。
- F12打开开发者工具 → Network → 刷新页面 → 点HTML请求 → 查
Response Headers里的Content-Type - Nginx配置要加：
add_header Content-Type "text/html; charset=utf-8";（注意：不是charset utf-8;，那是给静态文件用的） - Node.js/Express：
res.set("Content-Type", "text/html; charset=utf-8");必须在res.send()之前调用 - PHP：
header("Content-Type: text/html; charset=utf-8");必须在任何输出（包括空格、BOM）之前调用
真正卡住人的地方，往往不是“没写meta”，而是“写了但文件不是UTF-8”，或者“文件是UTF-8但带BOM”，又或者“服务端头里悄悄写了gbk”。三个环节得一个个验，不能只改一处就以为好了。
