必须放在最开头，因浏览器解析html时仅扫描前1024字节确定编码，若其被注释、或阻隔，则fallback至系统默认编码（如iso-8859-1/gbk），导致乱码、js语法错误及dom异常；同时文件须存为utf-8无bom格式，且服务器响应头charset优先级更高，三者缺一不可。
<meta charset="UTF-8"> 是唯一推荐写法，必须放在 最前面，且文件本身必须以 UTF-8（无 BOM）保存——缺一不可。
为什么<meta charset>必须放在
浏览器解析 HTML 时，会在读到第一个非 ASCII 字符前就尝试确定编码。如果 <meta charset> 被 <title></title>、<script></script> 或注释挡在后面，它可能根本来不及生效，页面就已按默认编码（如 Windows-1252 或 GBK）开始解码，乱码已成定局。
常见错误包括：
- 把
<meta charset>写在<title></title>后面 - 在
顶部加了注释或空行 - 用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">替代——HTML5 中不推荐，且容易拼错http-equiv
怎么确认文件实际编码和声明一致
编辑器右下角显示的编码格式 ≠ 文件真实编码。尤其 Windows 记事本默认存为 ANSI 或 UTF-16，VS Code 默认 UTF-8 但可能误点“UTF-8 with BOM”。
实操建议：
- VS Code / Sublime Text / Notepad++：右下角点击编码名 → 选 “Save with Encoding” → 明确选
UTF-8（不是UTF-8 with BOM） - 用命令行快速验证：
file -i index.html（Linux/macOS）或certutil -hashfile index.html SHA256配合 hex 查看 BOM 头（Windows） - 打开 Chrome DevTools → Network → 刷新 → 点开 HTML 请求 → 查 Response Headers 中
content-type是否含charset=utf-8；若为iso-8859-1或缺失，则 Web 服务器未配好，<meta>会被忽略
Web 服务器没配 charset 时怎么办
本地双击 index.html（file:// 协议）时，浏览器只认 <meta charset>；但通过 http://localhost 访问时，HTTP 响应头中的 Content-Type 优先级更高，会覆盖 <meta>。
不同环境补救方式：
- Python
http.server：默认不发 charset 头，<meta>有效；但别依赖它上线 —— 生产环境必须配服务器 - Apache：在
.htaccess或主配置中加AddDefaultCharset UTF-8 - Nginx：在
server或location块中加charset utf-8; - VS Code Live Server 插件：默认带
charset=utf-8响应头，可直接用
最容易被忽略的一点：改完 <meta charset> 后没重存文件，或编辑器自动转码失败——乱码问题往往不是标签写错了，而是文件底层字节没对上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
