不是设置编码，而是告知浏览器用 utf-8 解码文件；若文件实际编码不匹配（如存为 gbk 或含 bom）、http 响应头冲突、标签位置靠后或写法错误，均会导致乱码。
meta charset 能直接决定浏览器用什么编码解析 HTML 内容，不是“能改善”，而是“不设就大概率乱码”。只要 charset 声明和文件实际保存的编码不一致，中文、日文、繁体字等非 ASCII 字符基本都会出问题。
为什么 meta charset="UTF-8" 多数情况下有效
现代编辑器（VS Code、Sublime、WebStorm）默认以 UTF-8 无 BOM 保存 HTML 文件；主流浏览器（Chrome、Firefox、Edge）也优先按 meta charset 指定的编码读取内容。两者对齐，就能正确映射字节到汉字。
- 若文件实际是 UTF-8 编码，但写成
meta charset="gb2312"：浏览器会把 UTF-8 的多字节序列当成 GB2312 单字节解，显示 或一堆问号 - 若文件实际是 GBK 编码，但写成
meta charset="UTF-8"：浏览器强行按 UTF-8 解，常见现象是“中”变成“涓”、“文”变成“鏂” -
meta charset必须放在最靠前的位置（最好在<title></title>之前），否则部分浏览器可能已开始解析并误判编码
HTML5 之前用 meta http-equiv 的兼容性陷阱
老项目或遗留系统里常看到：<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">。它在语义上等价于 meta charset，但存在两个现实问题：
- HTTP 响应头中若带了
Content-Type: text/html; charset=GBK，它会被覆盖——而很多本地双击打开的 HTML 文件没有 HTTP 头，此时它才起作用 - IE6–8 对
http-equiv的解析更严格，如果该标签不在前 1024 字节内，可能被忽略 - 不要混用两种写法，比如同时写
meta charset和meta http-equiv，浏览器行为未定义，某些版本会以第一个为准，有些则取后者
编辑器保存编码和 meta charset 必须同步
乱码根本原因从来不是 HTML 标签本身，而是“存的编码”和“说的编码”不一致。检查顺序应该是：
- 用 VS Code 打开 HTML 文件 → 右下角看当前编码（如显示 “UTF-8” 或 “GBK”）→ 点击它 → 选择 “Save with Encoding” → 选和
meta charset一致的编码 - 用记事本打开 → “另存为” → 底部“编码”下拉菜单必须匹配你写的
charset值（UTF-8 / ANSI（即系统默认，通常是 GBK）/ Unicode（即 UTF-16 LE）） - 命令行可快速验证文件实际编码：
file -i index.html（Linux/macOS）或chcp+ 查看 BOM（Windows）
服务器响应头比 meta charset 优先级更高
当 HTML 通过 HTTP 服务访问（比如 http://localhost:3000），服务器返回的 Content-Type 响应头会覆盖 meta charset。例如：
Content-Type: text/html; charset=GBK
即使页面里写了 <meta charset="UTF-8">，浏览器仍按 GBK 解析。排查方式：
- 打开浏览器开发者工具 → Network → 刷一次页面 → 点 HTML 请求 → 查看 Response Headers 中的
Content-Type - Node.js 用 Express 时，默认不设 header，走浏览器自主判断；若用了
res.set("Content-Type", "text/html; charset=utf-8")，就必须和文件编码一致 - 静态托管（如 GitHub Pages、Vercel）通常强制 UTF-8，但 Nginx/Apache 配置错误时可能返回
charset=iso-8859-1，这种错很难一眼发现
真正容易被忽略的点：BOM。UTF-8 文件若带 BOM（EF BB BF），某些旧版 IE 会识别，但多数现代工具默认保存无 BOM UTF-8；而一旦加了 BOM，又在 meta charset 里写 UTF-8，反而可能触发双重解码异常——所以统一用无 BOM UTF-8 + meta charset="UTF-8" 是最稳组合。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
