meta charset="utf-8"必须置于最开头且文件为utf-8无bom编码，否则浏览器扫描前1024字节失败将回退系统默认编码（如windows的gbk）导致乱码。
meta charset="UTF-8" 必须写，但光写它几乎没用——除非你同时确保文件本身是 UTF-8 编码、HTTP 响应头没覆盖它、且没被 BOM 或位置错误搞废。
为什么 meta charset="UTF-8" 经常失效
浏览器在解析 HTML 时，会按固定优先级决定用什么编码：先看 HTTP 响应头的 Content-Type，再看 <meta charset>，最后才 fallback 到默认（如 ISO-8859-1）。常见失效场景：
- 服务器返回
Content-Type: text/html; charset=GBK，哪怕 HTML 里写了meta charset="UTF-8"，浏览器也直接无视 -
<meta charset="UTF-8">没放在最开头，前面有空格、注释或<script></script>，部分浏览器（尤其旧版）会跳过解析 - 文件实际保存为 GBK 或 ANSI，但 meta 声明 UTF-8，字节流和声明对不上，直接乱码
- 用了 UTF-8 with BOM，BOM（
EF BB BF）卡在前面，导致 <code>meta不被识别（VS Code 默认不加 BOM，Notepad++ 默认加）
如何验证当前页面真正用的编码
别信编辑器右下角显示，要查真实生效的编码：
- 打开 Chrome DevTools → Network → 刷新页面 → 点 HTML 请求 → 查
Response Headers中的Content-Type字段 - 如果值是
text/html; charset=utf-8，说明 HTTP 头生效；如果是gbk或没带charset，就靠 meta，但前提是它得能被读到 - 在 Console 执行
document.characterSet，返回值就是浏览器最终采用的编码，最权威 - 用命令行查文件真实编码：
file -i your-page.html（Linux/macOS），或用十六进制编辑器看文件开头是否为EF BB BF
Apache/Nginx/Node.js 怎么统一设响应头
服务端控制比前端 meta 更可靠，优先配这里：
- Apache：在站点根目录或
.htaccess里加AddDefaultCharset UTF-8；或更明确地用Header set Content-Type "text/html; charset=UTF-8" - Nginx：在
server或location块里加charset utf-8;；注意不要和AddDefaultCharset冲突 - Node.js（Express）：在路由响应前加
res.set('Content-Type', 'text/html; charset=utf-8');，必须在res.send()之前调用 - 静态托管（GitHub Pages、Vercel、Netlify）：它们默认发
charset=utf-8，meta可作为兜底，但不能依赖
编辑器保存时最容易踩的坑
写对了 meta，存错了格式，等于白干：
- VS Code：右下角点击编码名称（如 “GBK”），选 “Save with Encoding” → “UTF-8”；确认不勾 “UTF-8 with BOM”
- Notepad++：编码 → 转为 UTF-8 编码（**不是** “UTF-8-BOM”）；“UTF-8-BOM” 是历史兼容产物，现代 HTML 完全不需要
- Sublime Text：File → Save with Encoding → UTF-8；它默认不加 BOM，相对安全
- 切记：改完后重新打开文件，再检查右下角是否真显示 “UTF-8”，有些编辑器只改内存不改磁盘
BOM 和响应头冲突、编辑器编码与文件实际编码错位、meta 位置被注释顶开——这些细节不出错，meta charset 才真有用。否则它只是 HTML 里一行看起来很努力的注释。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
