html5中唯一推荐做法是，须置于开头、之前；必须用双引号、大写utf-8、无斜杠，且文件实际编码必须为utf-8（无bom），否则仍会乱码。
直接在 </meta charset="UTF-8">
这是 HTML5 中唯一推荐、最简、最有效的做法。浏览器在解析 HTML 时，会优先扫描前 1024 字节寻找这个标签；只要它出现在 开头（<title></title> 之前），就能立即切换到 UTF-8 解码模式，避免乱码或 JS 语法错误。
- 必须写成
<meta charset="UTF-8">—— 双引号、大写UTF-8、无斜杠闭合（HTML5 不要求自闭合） - 不能写成
utf8、utf_8、unicode或UTF8，部分旧浏览器或解析器会忽略 - 不能放在
<script></script>或<title></title>后面，否则可能已按默认编码（如 GBK / ISO-8859-1）开始解析，导致 emoji、中文注释、JS 字符串报错 - 整个 HTML 文件只能有一个
<meta charset>，多写无效，后写的不覆盖前写的
为什么不用 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
这个写法是 HTML4/XHTML 遗留方案，本质是模拟 HTTP 响应头，现在已不推荐。它比 charset 属性多出空格、引号、冒号、分号等字符，某些严格解析器（如 Node.js 的 jsdom、部分 WebView）可能因格式微瑕而跳过；而且在 HTML5 中，charset 属性语义更明确、解析更快、兼容性更好。
- 它要求完整 MIME 类型写法：
text/html; charset=UTF-8，漏空格或分号就失效 - 在 XHTML 模式下需写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，但现代页面基本不用 XHTML - 如果和
<meta charset>同时存在，浏览器只认charset属性，另一个被忽略
写了 <meta charset="UTF-8"> 还乱码？先查文件实际编码
标签只是“声明”，不改变文件磁盘上的字节。如果用 Notepad++ 保存为 GBK、VS Code 误存为 UTF-8 with BOM、或者从 Word 直接另存为 HTML，那 charset 声明再准也没用——浏览器按声明解码，结果把 GBK 字节当 UTF-8 解，必然乱码。
- VS Code：右下角点击编码名称（如
UTF-8或GBK），选Save with Encoding → UTF-8（不要选UTF-8 with BOM） - Notepad++：菜单栏
编码 → 转为 UTF-8 编码（不是“UTF-8-BOM”） - 终端验证（Linux/macOS）：
file -i your.html看输出是否含charset=utf-8；Windows 可用 PowerShell：Get-Content your.html -Encoding Byte | Select -First 3检查开头是否为EF BB BF（BOM）
HTTP 响应头里的 Content-Type 和 <meta charset> 谁说了算？
HTTP 响应头的 Content-Type: text/html; charset=... 优先级更高，但仅当它明确指定了 charset 时才生效。如果响应头没带 charset（比如 Apache 默认不加、Nginx 未配 charset utf-8;），浏览器才会退回到 <meta charset>。
- 本地双击打开 HTML 文件（
file://协议）：没有 HTTP 响应头，完全依赖<meta charset> - GitHub Pages、Vercel、Netlify 等静态托管：默认响应头带
charset=utf-8，但依然建议保留<meta charset>，以防离线缓存或调试时绕过服务端 - PHP/Node.js 后端：若手动设置了
header('Content-Type: text/html; charset=GBK');，哪怕 HTML 里写了UTF-8，也会按 GBK 解析——此时必须统一后端 header 和前端声明
<meta> 有效得多。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
