页面出现方块字、问号或乱码，八成是文件实际编码、HTTP响应头、HTML meta声明三者不一致；需用file -i（Linux/macOS）或PowerShell查BOM（Windows）确认真实编码，删UTF-8 BOM，并确保Content-Type响应头优先于meta charset生效。
页面出现方块字、问号或乱码，八成是编码设置没对齐——不是单看 <meta charset="UTF-8"> 写没写，而是文件实际编码、HTTP 响应头、HTML 声明三者是否一致。
怎么看文件真实编码（别信编辑器右下角显示）
VS Code 右下角写着 “UTF-8”，不代表文件真是 UTF-8；它可能只是“以 UTF-8 解释当前字节”，而文件本身存的是 GBK。真正判断靠字节：
- Linux/macOS 下运行
file -i your.html，输出含charset=utf-8才算实锤 - Windows PowerShell 运行
Get-Content your.html -Encoding Byte | Select -First 3，若结果是239 187 191，说明开头有 BOM（EF BB BF），属于 UTF-8 with BOM —— 多数 Web 场景该删 - Notepad++：菜单栏「编码」→ 看当前标注，再点「转为 UTF-8 无 BOM 编码」并保存
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只扫描 HTML 前 1024 字节来识别编码，且优先认 <meta charset>，但前提是它得在扫描范围内、且前面没干扰：
- 必须放在
开始后**紧挨着的第一行**，前面不能有空行、BOM、注释或<script></script> - 如果文件开头是 BOM（
EF BB BF），浏览器可能跳过它，直接按系统默认（如 Windows 的 GBK）解码前几个字节，导致<meta>标签本身被读歪，进而整个声明失效 - 验证方法：在 Chrome DevTools 的 Elements 面板里，右键查看源码（不是渲染后 DOM），确认
<meta charset="UTF-8">是否出现在最开头、无前置字符
HTTP 响应头比 <meta> 更强势
服务器返回的 Content-Type 响应头，会直接覆盖 HTML 里的 <meta charset>，哪怕后者写对了也白搭：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Network → 刷一下页面 → 点 HTML 请求 → 查 Response Headers → 找
content-type字段 - 如果值是
text/html; charset=gbk或压根没charset，那前端写的<meta charset="UTF-8">就被无视 - Nginx 配置要加
charset utf-8;（在server或location块内）；Apache 要在.htaccess加AddDefaultCharset UTF-8；Express 中用res.set('Content-Type', 'text/html; charset=utf-8')，不能只靠res.sendFile()
本地双击打开（file:// 协议）时唯一能靠的只有 <meta>
没有 HTTP 服务，就没有响应头，此时浏览器完全依赖 HTML 自身声明和文件编码：
- 必须确保文件是纯 UTF-8（无 BOM），且
<meta charset="UTF-8">是第一个标签 - VS Code 保存时选「Save with Encoding → UTF-8」，别选「UTF-8 with BOM」；Sublime Text 同理，Save with Encoding → UTF-8
- 如果 VS Code 左下角显示「GBK」，先「Reopen with Encoding → UTF-8」，再「Save with Encoding → UTF-8」，否则只是“假装保存为 UTF-8”
最容易被忽略的一点：BOM 不是“看不见的空白”，它是三个真实字节，会卡在解析起点，让浏览器第一眼就误判编码。删 BOM 和校验响应头，比反复改 <meta> 有效十倍。
