必须将<meta charset="UTF-8">置于<head>最开头（紧随<head>标签后、任何其他内容前），否则浏览器仅扫描前1024字节，遇BOM、注释、空格或<script>即中断并回退系统默认编码（如GBK或ISO-8859-1），导致中文、emoji等乱码；且需确保HTTP响应头Content-Type中的charset与之严格一致，否则以响应头为准。
必须在 <head> 中声明 <meta charset="UTF-8">
浏览器不会自动猜编码，不显式声明就可能用系统默认（如 Windows-1252 或 GBK），导致中文、emoji、特殊符号显示为乱码。这个 <meta> 标签必须放在 <head> 最前面（紧随 <title> 之前或之后都可，但不能晚于其他 <meta>），且不能写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> —— 后者兼容性差，部分旧版 IE 解析不稳定。
<meta charset> 和 HTTP 响应头 Content-Type 要一致
如果服务端返回的 HTTP 响应头里有 Content-Type: text/html; charset=GBK，而 HTML 里又写了 <meta charset="UTF-8">，浏览器会以响应头为准（优先级更高），<meta> 就被忽略。常见踩坑点：
- 本地用 VS Code 直接双击打开
.html文件（file://协议），此时无 HTTP 响应头，完全依赖<meta>，漏写必乱码 - Nginx/Apache 配置了默认
charset GBK，但前端代码全用 UTF-8，结果线上和本地表现不一致 - Node.js 的
res.setHeader('Content-Type', 'text/html')没带; charset=utf-8，导致响应头缺失编码声明
不要依赖 BOM，也别用 @charset 替代 <meta>
@charset "utf-8" 是 CSS 文件里的规则，对 HTML 文档无效；BOM（Byte Order Mark）是 UTF-8 文件开头的三个字节 EF BB BF，虽能辅助识别，但：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 某些编辑器（如老版本 Notepad++）保存时默认加 BOM，而 Git 会把它当二进制内容处理，引发 diff 异常
- PHP 等服务端脚本若输出前有 BOM，会导致 header 已发送错误
-
<meta charset="UTF-8">显式声明比 BOM 更可靠、更通用
验证是否生效：看 document.characterSet 和开发者工具 Network 面板
在浏览器控制台执行 document.characterSet，返回值应为 "UTF-8"；同时在 Network 面板选中 HTML 请求，检查 Response Headers 中的 content-type 字段是否含 charset=utf-8。两者不一致时，以后者为准——这意味着问题出在服务端配置，不是 HTML 写错了。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是服务端与前端声明的协同。只改 HTML 不碰服务器配置，上线后照样乱码。
