浏览器误判编码时，应先查Network中Content-Type响应头是否缺失或错误（如为GBK或无charset），再用file -i和xxd/Get-Content验证HTML文件实际编码及BOM存在与否，因BOM或响应头错误会导致<meta charset="UTF-8">失效。
怎么看浏览器是否误判了编码
乱码不是“文字坏了”，而是浏览器用错规则解开了字节。先确认是不是它自己猜错了：打开开发者工具（F12），切到 Network 标签页，刷新页面，点主 HTML 请求，在 Response Headers 里找 Content-Type。如果值是 text/html; charset=GBK 或压根没写 charset，哪怕你写了 <meta charset="UTF-8">，浏览器也会优先信响应头——这就不是 HTML 文件的问题，是服务器配置错了。
怎么验证 HTML 文件本身是否真为 UTF-8
编辑器右下角显示“UTF-8”不等于文件真是 UTF-8；它可能只是当前以 UTF-8 方式打开了一个 GBK 编码的文件。真正要看的是文件磁盘上的字节：
- Linux/macOS：运行
file -i yourfile.html，看输出是否含charset=utf-8 - 再执行
head -c 4 yourfile.html | xxd，如果开头是ef bb bf，说明带 BOM——而 BOM 会卡在<meta charset>前面，导致该标签被跳过 - Windows PowerShell：运行
Get-Content yourfile.html -Encoding Byte | Select -First 3，输出239 187 191就是 BOM
为什么 <meta charset="UTF-8"> 写了也无效
这个标签只有两个条件满足才起作用：它必须出现在 HTML 的前 1024 字节内，且前面不能有任何字符（包括空格、换行、注释、BOM）。常见失效场景：
-
<meta charset="UTF-8">写在<title>后面，或被<script>、<style>挡住 - 文件开头有 BOM（
ef bb bf），浏览器扫描前 1024 字节时先读到了 BOM，接着读到的就不是合法 ASCII 开头的<meta，直接放弃识别 - 写了
<meta charset="utf8">或<meta charset="UTF8">—— 只有UTF-8是标准值，大小写和连字符缺一不可
怎么区分是编码问题还是字体问题
复制网页上乱码的文字，粘贴到记事本或 VS Code 里：
立即学习“前端免费学习笔记（深入）”；
- 如果粘贴出来还是“ä¸æ–‡”“鎴戞槸”这类西文符号 → 是编码误读，原始字节还在，可修复
- 如果粘贴出来是“中”“文”，但网页上显示方框、空白或“” → 是字体缺失或不支持该字形，跟编码无关
- 如果只有一小段中文异常（比如评论区某条），其他都正常 → 很可能是数据库字段用了不同编码存入，或接口返回时没设好响应头
<meta charset> 就彻底失效——不是你写得不对，是它根本没机会被执行。 
