最常被忽略的是HTTP响应头Content-Type缺失charset，导致浏览器回退到ISO-8859-1或GBK而乱码；需检查DevTools Network中HTML请求的Response Headers，确保为text/html; charset=utf-8，并清除BOM、校验位置及编码一致性。
Chrome DevTools Network 面板里 Content-Type 响应头没 charset
这是最常被忽略的一环：即使 <meta charset="UTF-8"> 写对了，HTTP 响应头里 Content-Type 是 text/html（没带 charset=...），浏览器就可能 fallback 到 ISO-8859-1 或 GBK，直接显示乱码。
实操建议：
- 打开 Chrome DevTools → Network → 刷新页面 → 点击 HTML 请求 → 查看 Response Headers 下的
content-type - 如果值是
text/html; charset=gbk或text/html（无 charset），说明服务端配置优先级更高，<meta>已被覆盖或忽略 - Nginx 配置需在
http、server或location块中加charset utf-8;；Apache 需确认.htaccess或httpd.conf里有AddDefaultCharset UTF-8，且没有AddDefaultCharset GBK冲突 - Node.js/Express 中，
res.sendFile()或res.send()之前必须调用res.set('Content-Type', 'text/html; charset=utf-8')，不能只靠模板拼接
VS Code 显示“UTF-8”但文件实际含 BOM
VS Code 右下角写着 “UTF-8”，只是表示它当前以 UTF-8 解码该文件，并不等于文件磁盘上就是纯 UTF-8 —— 它很可能存的是 UTF-8 with BOM，也就是开头多了 EF BB BF 三个字节。
这个 BOM 会卡在 <meta charset="UTF-8"> 前面，导致浏览器在前 1024 字节扫描时根本找不到 <meta> 标签，从而失效。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 在 VS Code 中按
Ctrl+Shift+P→ 输入 “Save with Encoding” → 选UTF-8（注意：不是 “UTF-8 with BOM”） - Linux/macOS 下验证：
head -c 3 index.html | xxd，输出00000000: efbb bf就说明有 BOM，需清除 - Notepad++ 中：编码 → 转为 UTF-8（无 BOM）→ 保存；Sublime Text 同理，保存时选 “UTF-8” 编码，不勾 “BOM”
- 切记：HTML 文件不该有 BOM；JS/CSS 文件若有 BOM，还会触发
Uncaught SyntaxError: Invalid or unexpected token
写对了却仍乱码：位置和干扰项问题
<meta charset="UTF-8"> 必须出现在 开始后、前 1024 字节内，且前面不能有任何非 ASCII 内容。一旦被注释、空格、BOM、<title></title> 或 <script></script> 挤占位置，它就失效。
实操建议：
- 把
<meta charset="UTF-8">放到的第一行，紧贴标签后，前面不要空行、空格、注释 - 删掉所有类似
<!-- 注释 -->或<title>...</title>出现在<meta charset>之前的代码 - 检查是否误写成
<meta charset="utf8">或<meta charset="UTF8">—— 只有"UTF-8"是 HTML5 标准值，大小写敏感 - 用
file -i index.html确认文件实际编码；用head -n 5 index.html直接看开头几行，确认<meta>是否真在最靠前位置
本地 file:// 协议下 meta charset 完全无效
当双击 HTML 文件用 file:// 打开时，没有 HTTP 服务器，也就没有响应头。此时浏览器只依赖 <meta charset>，但它必须满足两个硬条件：纯 UTF-8（无 BOM）、且位于前 1024 字节内。稍有偏差，就会 fallback 到系统默认编码（Windows 常为 GBK）。
实操建议：
- 开发阶段绝不用双击打开 HTML；改用本地服务器：VS Code 安装 Live Server 插件，或命令行运行
npx serve、python3 -m http.server - 确认文件无 BOM（见上一条），且
<meta charset="UTF-8">是内第一个标签 - 避免在
里引入外部 CSS/JS，因为它们可能提前触发解析，挤压<meta>的扫描窗口 - 如果必须离线使用，可考虑生成一个带
Content-Type头的本地服务，或改用 Electron 等容器化方案绕过限制
BOM 和响应头缺失是最隐蔽也最容易被当成“已修复”的点——它们不报错，只静默 fallback，而且不同浏览器 fallback 行为还不一致。真正排查时，得同时盯住三处：文件磁盘内容（xxd / file -i）、HTTP 响应头（DevTools Network）、以及 DOM 解析起点（ 实际结构）。
