charset声明必须与文件实际编码、HTTP响应头、编辑器保存格式三者完全一致，否则必然乱码；浏览器优先采用响应头charset，其次BOM，最后meta标签，三者须统一为UTF-8无BOM。
charset 声明必须与文件实际编码、HTTP 响应头、编辑器保存格式三者完全一致，否则必然出现乱码——不是“可能”，而是浏览器直接按错码解释字节流，连报错都不会给。
为什么 <meta charset="UTF-8"> 放在 <head> 开头还不够？
它只是“提示”，不是强制指令。浏览器在解析 HTML 时，会优先检查 HTTP 响应头里的 Content-Type；如果响应头里写了 charset=GBK，哪怕你写了十遍 <meta charset="UTF-8">，浏览器也只认响应头。
常见错误现象：
- 本地双击打开 HTML 文件（无 HTTP 服务）：浏览器 fallback 到系统默认（Windows 常为 GBK），
<meta>才起作用 - Nginx/Apache 未配置
charset utf-8：响应头缺失或写错，<meta>被忽略 - PHP 输出前已发过 header：比如
header('Content-Type: text/html');没带charset，后续<meta>无效
UTF-8 文件保存时要不要带 BOM？
不要。BOM（EF BB BF）是三个字节的签名，对 UTF-8 来说非标准且有害：
立即学习“前端免费学习笔记（深入）”；
- IE 和旧版 Edge 会识别 BOM 并正确处理，但现代 Chrome/Firefox/Safari 会把它当普通字符——导致
<meta charset>不在前 1024 字节内，被跳过 - Node.js 的
fs.readFileSync()读出的字符串开头含 BOM，若用于拼接 HTML 模板，可能触发Uncaught SyntaxError: Invalid or unexpected token - VS Code 默认保存为 “UTF-8”（无 BOM），但若手动选了 “UTF-8 with BOM”，就得改回来
验证方式：file -i your.html（Linux/macOS）或用十六进制编辑器看开头三字节是否为 ef bb bf。
服务器配置和前端代码怎么同步 charset？
不能只靠 HTML 里写一行 <meta> 就完事。真实环境里，三处必须对齐：
- HTTP 响应头：
Content-Type: text/html; charset=UTF-8（Nginx 加charset utf-8;，Express 用res.set('Content-Type', 'text/html; charset=utf-8')） - HTML 文件本身：用编辑器保存为 UTF-8（无 BOM），且
<meta charset="UTF-8">是<head>中第一个标签（不计空白和注释） - 外部资源：JS/CSS 文件也必须是 UTF-8（无 BOM），且不能依赖已废弃的
<script charset="UTF-8">—— HTML5 中该属性已被 ignore
最容易被忽略的是：Webpack/Vite 等构建工具输出的 HTML，其 <meta> 是模板生成的，但源文件（如 index.html）若本身是 GBK 编码，构建后仍会乱码——得先改源文件编码，再构建。
字符编码问题从来不是“写了就对”，而是字节流从磁盘→网络→内存→渲染的每一步，都得确保解释规则没被悄悄覆盖。一个错位的 BOM、一行漏掉的 Nginx 配置、一次编辑器误保存，都足以让中文变成方块，emoji 变成问号。
