<meta charset="UTF-8">必须置于<head>最开头、<title>之前且仅一次，否则浏览器扫描前1024字节失败，将fallback至系统默认编码（Windows为GBK，macOS/Linux为ISO-8859-1），导致中文乱码、JS报Invalid or unexpected token、CSS中文注释失效。
meta charset 必须写在 <head> 开头、<title> 之前，且只能出现一次——这是单文件 HTML 小工具能正确显示中文、emoji 和运行 JS 的底线。
为什么 meta charset="UTF-8" 要放在最前面
浏览器解析 HTML 时，只扫描前 1024 字节找 meta charset；如果它被 <script>、注释或空格挡在后面，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），导致：
- 中文变成乱码（如 “你好” 显示为 “ä½ å¥½”）
- JS 报错
Uncaught SyntaxError: Invalid or unexpected token（尤其含中文字符串或 emoji 时） - CSS 注释里的中文无法识别，甚至破坏后续规则
所以不是“写了就行”，而是“位置错了就等于没写”。
别用 meta http-equiv="Content-Type"
这个写法是 HTML4/XHTML 遗留方案，依赖 HTTP 响应头模拟，现代浏览器已不推荐：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- HTML5 中
meta charset优先级更高，两者共存时后者被忽略 - 某些 WebView（如旧版 Android）、Node.js 的 jsdom 环境会因空格或大小写（如
charset=utf8）直接失效 - 写成
charset=utf8、UTF8、utf_8都不合法，必须是UTF-8（带连字符、大写 U、T、F）
文件保存编码必须和 meta 声明一致
meta charset="UTF-8" 只是告诉浏览器“请按 UTF-8 解码”，但前提是文件本身真是 UTF-8 编码。常见错配场景：
- 用 VS Code 新建文件，默认是 UTF-8（无 BOM），但如果手动选了 “UTF-8 with BOM”，部分旧环境可能误判
- 用 Notepad++ 打开再保存，若没点 “转为 UTF-8 编码”，很可能存成 GBK
- 从 Word 直接另存为 HTML，几乎必然带 GBK 或乱码的 meta 标签
验证方法：file -i your.html（Linux/macOS）或 PowerShell 中 Get-Content your.html -Encoding Byte | Select -First 3 查看开头三字节是否为 EF BB BF（BOM）；若不是，且声明了 UTF-8，就说明文件实际编码不匹配。
内嵌 JS/CSS 里中文怎么不出错
只要 meta charset 位置正确、文件真实编码匹配，内嵌 JS 和 CSS 就不会因编码崩掉。但注意两个细节：
- JS 字符串里的中文无需转义，直接写
console.log("测试")即可 - CSS 中文类名或属性值（如
.按钮 { display: block; }）完全合法，但别在style属性里混用引号嵌套，比如style="content: '▶';"比style='content: "▶";'更稳妥 - 如果 JS 里要动态插入含中文的 HTML，用
textContent而非innerHTML，避免 XSS 风险
真正容易被忽略的，是文件保存动作本身——改完 meta 标签后，忘记用编辑器重新以 UTF-8 编码保存文件，结果还是在跑一个 GBK 实体的 HTML。
