必须位于最开头、前1024字节内且前面无任何字符（含bom、空格、注释），否则浏览器跳过并fallback至系统默认编码（如windows的gbk）导致乱码。
meta charset 必须写对、存对、传对，三者缺一不可。只加一行 <meta charset="UTF-8"> 不等于网页就真用 UTF-8 了。
为什么 meta charset 写了却还是乱码
浏览器解析 HTML 时，只扫描前 1024 字节找 charset 声明；如果它被注释、<title></title> 或空格挡住，就会跳过。更关键的是：这个标签必须出现在 开头、任何其他内容（包括注释、空行、<title></title>）之前。
-
<!-- 注释 --><meta charset="UTF-8">→ 失效 -
<title>页面</title> <meta charset="UTF-8">→ 失效 -
<meta charset="utf8">→ 拼写错误，utf8不合法，必须是UTF-8 -
<meta charset="UTF-8"> <title>页面</title>→ 正确顺序
怎么确认 HTML 文件本身是 UTF-8 编码（含 BOM 判断）
编辑器显示“UTF-8”不等于文件真是 UTF-8 —— 很多编辑器会把无 BOM 的 GBK 文件也标成 UTF-8。BOM 是关键证据：UTF-8 BOM 是三个字节 EF BB BF，位于文件最开头。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- VS Code：右下角状态栏点击编码名称 → 选 “Save with Encoding” → “UTF-8”（默认无 BOM）或 “UTF-8 with BOM”（显式带 BOM）
- 命令行检测（macOS/Linux）：
head -c 4 index.html | xxd，输出含ef bb bf表示有 BOM - PowerShell（Windows）：
Get-Content index.html -Encoding Byte | Select -First 3，结果为239, 187, 191即 BOM - 无 BOM 更安全：现代浏览器都支持无 BOM UTF-8，且 BOM 可能导致 PHP 输出前置空白、Node.js
require()报错
怎么验证 HTTP 响应头里的 charset 是否生效
HTTP Content-Type 响应头优先级高于 meta charset。如果服务器返回 Content-Type: text/html; charset=GBK，哪怕你写了 UTF-8 meta，浏览器也会强制用 GBK 解析。
- Chrome DevTools → Network → 刷新页面 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type字段 - 本地开发用
file://协议时，HTTP 头不存在，完全依赖meta和文件编码，此时 BOM 尤其重要 - Node.js/Express 设置：
res.set('Content-Type', 'text/html; charset=UTF-8') - Apache 配置：
AddDefaultCharset UTF-8；Nginx：charset utf-8;
怎么在浏览器里快速核对最终生效的编码
别只信开发者工具里看到的 meta 标签 —— 浏览器实际用的编码，得看运行时的 document.characterSet。
- 打开控制台（F12），输入
document.characterSet，返回"UTF-8"才算真正生效 - 再检查
document.querySelector('meta[charset]')?.getAttribute('charset')，确认 meta 标签存在且值正确 - 如果两者不一致，说明 HTTP 头或文件编码覆盖了 meta；如果都是
UTF-8但页面仍乱码，大概率是文件保存时用了错误编码（比如编辑器标着 UTF-8，实则存为 GBK）
最容易被忽略的点：文件编码、meta 标签位置、HTTP 响应头，这三者要同时对齐。其中文件编码是地基 —— 它错了，后面全白搭；而 document.characterSet 是唯一可信的 runtime 结果，别只看代码写了什么。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
