最短生效路径：确保<meta charset="UTF-8">在<head>第一行且无前置字符（含BOM、空格、注释），HTML文件本身保存为UTF-8无BOM编码；二者同时满足，本地双击即可解决90%中文乱码。
直接上最短生效路径：确保 meta charset="UTF-8" 在 <head> 开头第一行，且 HTML 文件本身是 UTF-8（无 BOM）编码保存——这两点同时满足，本地双击打开就能立刻解决 90% 的中文乱码。
确认文件真实编码不是 UTF-8 with BOM
VS Code 右下角显示 “UTF-8” 不代表文件就是 UTF-8；它可能实际存为 GBK 或带 BOM 的 UTF-8。BOM（EF BB BF）会卡在文件开头，导致浏览器跳过 <meta charset> 解析。
- Linux/macOS 下运行：
file -i index.html，输出必须含charset=utf-8；若为charset=us-ascii或charset=iso-8859-1，说明根本没存成 UTF-8 - Windows PowerShell 中运行：
Get-Content index.html -Encoding Byte | Select -First 3，若输出239 187 191，就是 BOM —— 必须删掉 - VS Code 中按
Ctrl+Shift+P→ 输入Change File Encoding→ 选Save with Encoding→UTF-8（注意不是UTF-8 with BOM）
meta charset 必须放在 <head> 最前面
浏览器只扫描前 1024 字节找 charset 声明，且一旦遇到空格、注释、BOM 或其他标签就停。哪怕 <meta charset="UTF-8"> 写对了，位置错也白搭。
- 必须紧贴
<head>开始，前面不能有任何字符（包括换行、空格、<!-- 注释 -->） - 写法必须严格为：
<meta charset="UTF-8">——utf8、UTF8、utf_8全部无效 - 禁止和
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">并存，否则可能触发兼容模式解析异常
HTTP 响应头会覆盖 meta，调试时别被本地测试骗了
双击打开 file:// 协议时，浏览器只认 meta；但只要走 HTTP（比如 http://localhost:3000），服务端返回的 Content-Type 头优先级更高 —— 这是线上乱码最常被忽略的点。
立即学习“前端免费学习笔记（深入）”；
- Chrome 打开开发者工具 →
Network→ 刷新 → 点 HTML 请求 → 查看Response Headers中的Content-Type - Nginx 配置里写
charset utf-8;要放在http或server块，不能只塞在location里 - Express 中用
res.sendFile()时，默认不带 charset，必须提前加：res.set('Content-Type', 'text/html; charset=utf-8')（顺序不能错）
真正棘手的是混合场景：HTML 是 UTF-8，但引入的 <script src="app.js"> 或 <link href="style.css"> 文件本身是 GBK 编码 —— 这时即使页面主体正常，JS 报错或 CSS 中文注释也会乱。所有外部资源的编码都得统一，不能只盯 HTML 一个文件。
