必须紧贴开头，位于前1024字节内且前面不能有任何字符（包括bom、空格、注释），否则浏览器回退默认编码（如iso-8859-1）导致中文、emoji乱码；文件保存编码须为utf-8无bom，且http响应头content-type charset优先级更高，三者必须统一。
meta charset 必须紧贴 开始标签
浏览器解析 HTML 时，只在前 1024 字节内寻找第一个 <meta charset>，一旦错过就回退到默认编码（通常是 ISO-8859-1），中文、emoji、特殊符号全变乱码。这不是“写了就行”，而是位置决定是否生效。
常见错误包括：
-
<meta charset="UTF-8">写在<title></title>或<script></script>后面 - 开头有空格、注释、BOM 头（如
EF BB BF）挡在前 - 误写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这在现代 HTML5 中已过时，且 Safari / 微信内置浏览器可能不识别
正确写法只有一种：
<meta charset="UTF-8"><title>页面标题</title>中间不能有任何字符，包括空行和注释。
文件保存编码必须是 UTF-8（无 BOM）
即使 <meta charset="UTF-8"> 写对了，如果文件本身用 GBK 或 UTF-8 with BOM 保存，浏览器拿到的字节流就不是 UTF-8，解码必然失败。VS Code 默认新建文件是 UTF-8，但打开旧文件时可能自动识别为 GBK，再一保存就出问题。
验证和修正方法：
- 在 VS Code 右下角确认显示 “UTF-8”，不是 “UTF-8 with BOM” 或 “GBK”
- 点击右下角编码名 → 选 “Save with Encoding” → 选 “UTF-8”（注意：不是 “UTF-8 with BOM”）
- 用命令行检查 BOM：
head -c 3 yourfile.html | xxd，输出含ef bb bf就说明有 BOM，需清除
HTTP 响应头 Content-Type 优先级高于 meta
如果服务器返回的 HTTP 响应头里是 Content-Type: text/html; charset=GBK，那 <meta charset="UTF-8"> 直接被无视。这是线上环境最常被忽略的一环。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
不同环境配置方式：
- Nginx：在
server或location块中加charset utf-8;（注意不是charset GBK;） - Apache：在
.htaccess中加AddDefaultCharset UTF-8 - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=UTF-8') - PHP：
header('Content-Type: text/html; charset=UTF-8');必须在任何输出之前调用
验证是否生效：打开 Chrome DevTools → Network → 刷新 → 点击 HTML 请求 → 查看 Response Headers 中的 Content-Type 字段。
document.characterSet 和实际解码方式要一致
浏览器最终用什么编码解 HTML，取决于三者是否统一：文件实际字节流 + HTTP 响应头 + <meta charset>。哪怕只有一处是 GBK，整个页面就按 GBK 解——哪怕你写了 UTF-8，它也当没看见。
快速自查命令（在控制台运行）：
document.characterSet返回值必须是
"UTF-8"；如果不是，说明至少有一个环节没对齐。此时不要改代码，先查响应头、再查文件编码、最后看 meta 位置。
最容易被忽略的是构建工具：Webpack/Vite 在处理 HTML 模板时，若源文件是 GBK，它不会自动转码，生成的产物仍是 GBK 字节流，<meta charset="UTF-8"> 就成了摆设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
