必须位于html文档前1024字节内、开头且在和之后、bom/注释/空格/其他标签之前；大小写敏感，仅"utf-8"合法；http响应头content-type中charset优先级更高。
检查网页是否声明了 <meta charset>
浏览器解析 HTML 时，会优先读取前 1024 字节内的 <meta charset="UTF-8"> 标签。如果它没出现在这个范围里，或者被注释、空格、BOM 或其他内容挡在前面，就大概率失效。
常见干扰项包括：
-
<!-- 注释 -->写在<meta charset>前面 - 文件开头存在 UTF-8 BOM（
EF BB BF），尤其在 Windows 记事本或旧版编辑器中保存时容易产生 -
<title></title>或其他标签意外提前出现在里，导致解析器隐式关闭 - 写成
<meta charset="utf8">或<meta charset="UTF-8">—— 只有"UTF-8"（带引号、大小写敏感）是 HTML5 合法值
验证文件实际保存编码是否匹配声明
编辑器显示“UTF-8”不等于文件真是 UTF-8 编码。很多编辑器只是按某种编码打开文件，但未真正以该编码保存。
快速验证方法：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- VS Code：右下角点击编码名称 → 选
Reopen with Encoding尝试UTF-8/GBK，看源码是否变正常；确认后点Save with Encoding并选UTF-8（勾选 “No BOM”） - macOS/Linux 终端：
file -i index.html查 MIME 类型，head -c 3 index.html | xxd看是否有 BOM - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，输出239 187 191即含 BOM
比对 HTTP 响应头中的 Content-Type
服务器返回的响应头中 Content-Type: text/html; charset=GBK 会直接覆盖 HTML 里的 <meta charset>，且优先级更高。
在浏览器开发者工具的 Network 面板中，刷新页面后点击 HTML 请求 → Headers → Response Headers，找 Content-Type 字段。常见问题：
- Nginx 没配
charset utf-8;（需加在 http/server/location 块中） - Apache 的
.htaccess缺AddDefaultCharset UTF-8 - Node.js（如 Express）没手动设头：
res.set('Content-Type', 'text/html; charset=utf-8') - Tomcat 的
server.xmlConnector 缺URIEncoding="UTF-8"
区分乱码类型再动手，别一上来就改 <meta>
不是所有“中文变问号”都该修 <meta charset>。先看现象：
- 整页中文全成 或 ? → 重点查响应头、文件保存编码、BOM
- 只有数据库字段或接口返回内容乱码 → 问题在后端连接或 SQL 查询编码（如 MySQL 的
SET NAMES utf8mb4） - 个别字显示为方框 □ → 字体缺失，跟编码无关，换字体或补字形
- 无痕窗口正常，原窗口异常 → 浏览器缓存或扩展干扰，先禁用扩展再试
最常被忽略的是：改完 HTML 和服务器配置后，忘了清浏览器缓存或服务端缓存。哪怕 <meta> 和响应头都对了，缓存的旧版本仍会持续显示乱码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
