<meta charset="UTF-8"> 必须位于 <head> 内第一个非空白、非注释子元素且格式严格为“UTF-8”，同时需确保HTML文件实际编码为UTF-8无BOM，并与HTTP响应头Content-Type中charset一致，三者缺一不可。
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只在解析 HTML 前 1024 字节内查找 <meta charset>，一旦被注释、BOM、空格或换行挡住，就会跳过并 fallback 到系统默认编码（比如 Windows 下的 GBK），直接导致中文显示为 。
-
<meta charset="UTF-8">必须是<head>内第一个非空白、非注释的子元素，理想位置在<title>之前 - 不能写成
<meta charset="utf8">或<meta charset="utf-8">—— 只有UTF-8（全大写、带连字符）是标准写法 - VS Code 显示 “UTF-8” 但实际存的是 UTF-8 with BOM？用
head -c 4 yourfile.html | xxd检查开头是否含ef bb bf；如有，需另存为纯 UTF-8
HTML 文件本身编码和 <meta charset> 不一致怎么办
声明是 UTF-8，但文件实际以 GBK 保存，浏览器按 UTF-8 解码 GBK 字节流，必然乱码。这不是标签写得不对，是文件“说谎”了。
- VS Code：右下角点击编码 →
Reopen with Encoding选 GBK（若当前显示乱码），确认内容正常后 →Save with Encoding→ 选UTF-8（明确不带 BOM） - Notepad++：菜单栏
编码 → 转为 UTF-8 编码（不是 “UTF-8-BOM”） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - Linux/macOS 终端验证：
file -i index.html应输出charset=utf-8；若为charset=iso-8859-1或charset=gbk，说明没改对
HTTP 响应头 Content-Type 覆盖 <meta charset>
当页面通过 HTTP 协议加载（http:// 或 https://），服务器返回的 Content-Type: text/html; charset=gbk 会直接覆盖 HTML 内部声明，哪怕 <meta charset="UTF-8"> 写得再规范也没用。
- Chrome/Firefox 开发者工具 →
Network→ 刷新 → 找到主 HTML 请求 → 查看Response Headers中的Content-Type - Nginx 配置加一行：
charset utf-8;（放在server或location块内，不要用add_header Content-Type，会重复） - Apache 的
.htaccess加：AddDefaultCharset UTF-8 - Node.js/Express：在
res.send()前调用res.set('Content-Type', 'text/html; charset=utf-8')
本地双击打开 HTML 时乱码，跟服务器无关
用 file:// 协议打开时，没有 HTTP 响应头，浏览器完全依赖 <meta charset> 和文件实际编码。这时常见陷阱是：编辑器误存为 GBK，却写了 UTF-8 声明。
立即学习“前端免费学习笔记（深入）”；
- 别信编辑器右下角显示 —— 它可能只是“猜测”，未必准确。先用
file -i或xxd确认真实编码 - VS Code 中，若打开 HTML 后中文显示为方块，先点右下角编码 →
Reopen with Encoding→ 试 GBK / GB2312，看到正常文字后再另存为 UTF-8 - Windows 记事本默认保存为 ANSI（即 GBK），务必避免用它编辑含中文的 HTML
<meta charset="UTF-8">”，而是三处编码——文件自身、HTML 声明、HTTP 响应头——必须严格对齐，且顺序和格式零容错。任何一环偏差，都会让浏览器放弃 UTF-8，悄悄切回 GBK。 
