必须紧贴后、位于最前面且仅出现一次，因浏览器仅扫描前1024字节识别编码，延迟声明或存在bom/空行/注释将触发默认编码（如iso-8859-1或gbk）导致中文乱码，后续声明无效。
<meta charset="UTF-8"> 必须写在 最前面，且只能出现一次——这是避免中文乱码最硬性的底线，其他所有设置都建立在这个前提上。
为什么<meta charset="UTF-8">必须紧贴
浏览器解析 HTML 时，会逐字节读取并尝试识别编码声明。一旦开头几 KB 内没看到有效的 <meta charset>，就会按默认编码（如 Windows-1252 或系统 locale）先解码一部分内容，导致中文字符被错误解释为乱码字节；后续再遇到 <meta charset="UTF-8"> 也无力回天。
- 常见错误：在
和之间加空行、注释或 BOM 字节（EF BB BF） - VS Code / Sublime 默认保存带 BOM 的 UTF-8 文件，会导致
<meta>失效——务必关掉“Save with BOM”选项 - 不要写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，它兼容性差，且不被现代解析器优先识别
HTML文件本身编码必须是UTF-8，且不含BOM
声明只是告诉浏览器“该怎么读”，但前提是文件磁盘里存的就是 UTF-8 编码的字节。如果编辑器用 GBK 保存了一个含中文的 HTML 文件，即使写了 <meta charset="UTF-8">，浏览器也会按 UTF-8 去解码 GBK 字节，结果就是一串 。
- VS 中：右下角点击编码名称 → “Save with Encoding” → 选 “UTF-8”（不是 “UTF-8 with BOM”）
- 命令行验证：
file -i your-page.html应输出charset=utf-8；若显示charset=iso-8859-1或charset=gbk，说明文件没存对 - Git 用户注意：
core.autocrlf不影响编码，但core.safecrlf可能因编码误判拒绝提交——建议统一设为false并靠编辑器约束
HTTP响应头与<meta>冲突时，以哪个为准
当服务器返回的 HTTP Header 中有 Content-Type: text/html; charset=GBK，而页面里又写了 <meta charset="UTF-8">，浏览器会优先采用 HTTP Header 的声明——这意味着后端配置错误会直接覆盖前端努力。
- 本地开发用 Live Server 或 Python
http.server时，默认不发 charset，此时<meta>生效 - Nginx 需显式配置：
charset utf-8;（在http或server块中） - Apache 要检查
AddDefaultCharset是否覆盖了 HTML 声明，建议设为off - Node.js/Express：确保没调用
res.set('Content-Type', 'text/html')而漏掉; charset=UTF-8
真正容易被忽略的是：<meta charset> 生效的前提是整个 HTML 文档从第一个字节开始就是 UTF-8 编码——声明和存储必须同步，缺一不可。任何一环用错编码（编辑器、保存方式、HTTP 头、甚至 Git diff 显示），都会让中文变成 。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
