必须同时确保文件实际保存编码、HTTP响应头、浏览器解析行为三者一致，缺一不可；常见原因包括：meta未置最前、文件实为GBK却声明UTF-8、file://协议下Chrome忽略meta、UTF-8 with BOM引发兼容问题、服务器未设置charset响应头。
直接改 <meta charset="UTF-8"> 不等于页面就真用 UTF-8 了，必须同时确保文件实际保存编码、HTTP 响应头、浏览器解析行为三者一致，缺一不可。
改 <meta charset> 但页面仍乱码的常见原因
写对了标签却没用，多半是下面几个环节脱节：
-
<meta charset="UTF-8">没放在最开头 —— 前面有注释、空格、<script></script>或 BOM 都会导致浏览器跳过识别 - 文件实际保存成了 GBK/ANSI，但
<meta>却声明 UTF-8 —— 浏览器按 UTF-8 解码 GBK 字节，必然乱码 - 本地双击打开 HTML 文件（
file://协议），Chrome 完全忽略<meta>，只靠文件 BOM 或编辑器提示猜编码 - 用了
UTF-8 with BOM：VS Code 默认如此，但 BOM 在某些场景（如 PHP 输出前）会引发额外换行或 JSON 解析失败
保存为 UTF-8（无 BOM）的具体操作
不同编辑器路径略有差异，核心是选「UTF-8」而非「UTF-8 with BOM」：
- VS Code：右下角点击当前编码（如
UTF-8或GBK）→ 选Save with Encoding→ 选UTF-8（注意不是带 BOM 的那个） - Notepad++：菜单栏
编码→转为 UTF-8（不是「UTF-8-BOM」）→ 再点保存 - Sublime Text：菜单
File→Save with Encoding→UTF-8 - 验证是否成功：用命令行查文件头三字节，Linux/macOS 运行
head -c 3 index.html | xxd，输出不应含ef bb bf；Windows 可用 PowerShell：Get-Content index.html -Encoding Byte | Select -First 3
本地打开 HTML 时 Chrome 强制指定编码的方法
双击本地文件时，Chrome 不读 <meta>，只能手动干预：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- F12 打开开发者工具 → 右上角
⋯→More tools→Rendering - 勾选
Emulate document charset→ 下拉选UTF-8 - 这个设置仅当前 DevTools 有效，关掉就失效；真正可靠的方式是起一个本地服务（如 VS Code Live Server 插件），让页面走
http://协议，此时<meta>和响应头才起作用
后端或服务器层面补一层 charset 声明
即使前端全配对了，Nginx/Apache/Node.js 若返回的 HTTP 响应头没带 charset，部分浏览器仍可能 fallback 到错误编码：
- Nginx：在
server或location块中加charset utf-8;（小写，不能写 UTF-8） - Apache：在站点根目录放
.htaccess，内容为AddDefaultCharset UTF-8 - Express（Node.js）：响应前加
res.set('Content-Type', 'text/html; charset=UTF-8'); - 验证方式：F12 → Network → 点开 HTML 请求 → Headers → Response Headers → 查
Content-Type是否含charset=utf-8
最容易被忽略的是：改完 <meta> 后没重新保存文件，或者保存时误选了带 BOM 的 UTF-8；而本地测试又只靠双击打开，根本没触发 HTTP 层逻辑。这种情况下，无论标签写得多标准，浏览器看到的永远是一堆错位字节。
