浏览器实际编码可通过F12→Network→刷新→点HTML请求→查Response Headers中Content-Type的charset值确认；该值优先级高于meta声明，若不一致或缺失则导致乱码。
怎么看浏览器实际用了什么编码
打开 Chrome 或 Edge，按 F12 → 切到 Network 标签 → 刷新页面 → 点击左侧 HTML 请求（通常是第一个）→ 在右侧 Response Headers 里找 Content-Type 字段。如果值是 text/html; charset=UTF-8，说明服务端发出了正确声明；如果显示 charset=GBK 或压根没带 charset，那问题大概率出在服务器配置或响应头设置上。
注意：Content-Type 声明优先级高于 <meta charset>，哪怕 HTML 里写了 <meta charset="UTF-8">，只要响应头强制指定 charset=GBK，浏览器就会按 GBK 解码——直接乱码。
怎么确认 HTML 文件本身存的是 UTF-8
文件内容和声明不一致是最常见的坑。不能只看编辑器右下角写着 “UTF-8”，那只是当前打开方式，不代表文件磁盘里真是 UTF-8 编码。
验证方法：
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- VS Code：右键文件 →
Reopen with Encoding→ 依次选UTF-8、GBK、ISO-8859-1，看中文是否突然变正常或更乱；确认后选Save with Encoding→UTF-8（务必勾选“不带 BOM”） - macOS/Linux 终端：
file -i index.html，输出含charset=utf-8才算实锤；再用head -c 3 index.html | xxd检查开头三字节，ef bb bf就是 BOM，得删 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就含 BOM
为什么 <meta charset="UTF-8"> 有时不起作用
这个标签只有在 HTML 前 1024 字节内被扫描到才生效。它前面不能有：
- BOM（
ef bb bf） - 注释（
<!-- 注释 -->） - 空行或多余空格（比如
<head>\n\n<meta charset="UTF-8">） -
<title>或其他标签提前出现
最稳妥的位置是：<head><meta charset="UTF-8"> 紧挨着，中间零空格、零换行、零注释。写成 <meta charset="utf8"> 或 <meta charset="UTF8"> 也不认——HTML5 只接受严格拼写 "UTF-8"。
外部资源（JS/CSS）的编码也要同步
就算 HTML 本身没问题，引入的 <script src="app.js"> 或 <link rel="stylesheet" href="style.css"> 如果文件不是 UTF-8 编码，或者没在响应头里声明 charset=UTF-8，里面的中文注释、字符串、CSS 中文内容照样会乱。
检查方式一样：在 Network 里点开 JS/CSS 请求 → 看 Response Headers 的 Content-Type 是否含 charset=UTF-8；再用 file -i 或编辑器确认文件实际编码。
真正容易被忽略的是：Nginx/Apache/Express 这些服务层对静态资源（.js/.css）默认不加 charset 响应头，必须显式配置。比如 Nginx 要在 location 块里补一句 charset utf-8;，否则浏览器可能按系统默认（如 Windows 是 GBK）去猜，一猜就错。
