file -i index.html 输出 charset= 后的值即真实编码，xxd -l 8 index.html 查看前8字节是否含 ef bb bf（bom），二者结合可准确判断html文件实际编码。
怎么看当前HTML文件实际用的什么编码
别光信编辑器右下角显示的“UTF-8”——它只是当前打开方式，不是文件真实字节。真正决定乱码的是文件开头那几个字节。
Linux/macOS 下用这两条命令最直接：
-
file -i index.html—— 看输出里charset=后面是什么 -
xxd -l 8 index.html—— 看前 8 字节，如果开头是ef bb bf，说明带 BOM；没这三字节但显示 UTF-8，就是无 BOM 的纯 UTF-8
Windows PowerShell 用：Get-Content index.html -Encoding Byte | Select -First 3，结果是 239 187 191 就是 BOM。
VS Code 里点右下角编码名 → 选 “Reopen with Encoding” 试 GBK / UTF-8 / ISO-8859-1，哪个能正常显示中文，基本就是原编码。
为什么 <meta charset="UTF-8"> 写了还是乱码
这个标签不是万能 fallback，它只在浏览器找不到更权威编码声明时才生效。优先级低于 HTTP 响应头里的 Content-Type，也低于文件本身的 BOM。
常见失效场景：
-
<meta charset="UTF-8">没写在开头 1024 字节内（比如前面有注释、空行、<script></script>） - 文件带 BOM，但服务器（如 Nginx）配置了
charset utf-8;，BOM 和响应头冲突，部分浏览器会忽略<meta> - 写成了
<meta charset="utf8">（少个连字符）或<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML5 不推荐，兼容性差） - 后端模板引擎（如 Thymeleaf、Jinja）动态删了或挪动了这个标签
怎么确认 HTTP 响应头里的编码设置
本地 file:// 协议不发响应头，<meta> 是唯一依据；但走 HTTP（比如 http://localhost:8080）时，必须看 Network 面板。
Chrome/Firefox DevTools → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 找 Content-Type 字段：
- 如果是
text/html; charset=GBK，哪怕页面写了<meta charset="UTF-8">，浏览器也按 GBK 解码 - 如果是
text/html; charset=UTF-8，那就和<meta>一致，大概率没问题 - 如果压根没这个字段，浏览器才退回到
<meta>或 BOM
Nginx 配置要加 charset utf-8;（放在 http / server / location 块里都行）；Apache 用 AddDefaultCharset UTF-8；Node.js（如 Express）需显式设 res.set('Content-Type', 'text/html; charset=utf-8')。
编辑器保存时最容易踩的坑
VS Code 默认“保存即 UTF-8”，但如果你曾手动选过其他编码再保存，它会记住并沿用——下次新建文件也可能继承错。
务必做两件事：
- 保存前点右下角编码名 → “Save with Encoding” → **选 “UTF-8”（不是 “UTF-8 with BOM”）**
- 在 VS Code 设置里搜
files.encoding，确保值是utf8；再搜files.autoGuessEncoding，建议关掉，避免自动猜错干扰判断
Sublime Text、Notepad++ 同理：保存时明确选 “UTF-8”（无 BOM），别依赖“自动检测”。BOM 在 HTML 里基本没好处，反而容易触发 fallback 到 GBK。
真正麻烦的不是某一处没设对，而是文件编码、HTTP 响应头、<meta> 标签三者不一致——只要有一处是 GBK 或 ISO-8859-1，就可能让整个页面中文变方块。检查时得三处并行比对，不能只盯一个地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
