<meta charset="UTF-8"> 必须位于 <head> 开头前1024字节内且无任何前置非ASCII内容（如BOM、注释、空行、<title>等），否则浏览器已按系统默认编码（如Windows的GBK）开始解析，后续声明失效；同时需确保HTML文件实际编码、HTTP响应头Content-Type与之完全一致。
为什么 <meta charset="UTF-8"> 放错位置会导致乱码
浏览器解析 HTML 时，前 1024 字节内就决定用什么编码解码后续内容。如果 <meta charset="UTF-8"> 不在 <head> 开头、而是卡在 <title> 后面或中间注释之后，它就来不及生效——浏览器已按系统默认（比如 Windows 的 GBK 或 macOS 的 ISO-8859-1）开始读取，后面再声明 UTF-8 也救不回前面错解的字节。
常见错误写法：
-
<head><title>首页</title><meta charset="UTF-8"></head>→<title>已触发解码，<meta>晚了 -
<head><!-- 注释 --><meta charset="UTF-8"></head>→ 注释本身可能含非 ASCII 字符，BOM 或乱码会提前污染缓冲区 -
<head><script>...</script><meta charset="UTF-8"></head>→ JS 内容若含中文，已被错误解码成乱码
正确顺序只有一条：<head><meta charset="UTF-8"><title>...，且不能有任何非 ASCII 字符、空行或 BOM 在它前面。
VS Code / Notepad++ 保存为 UTF-8 with BOM 还是 without？
BOM 是三字节标记 EF BB BF，加在文件开头。它对现代浏览器（Chrome/Firefox/Edge）基本无影响，但 IE 和某些老旧服务端逻辑（如 PHP 的 header()、Node.js 的 res.set()）会在输出 HTML 前因 BOM 被当作响应体内容，导致 HTTP 头发送失败。
立即学习“前端免费学习笔记（深入）”；
实操建议：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 纯静态 HTML 文件（直接双击打开或用
file://协议）→ 选UTF-8 with BOM，IE 更稳 - 通过 Web 服务器（Nginx/Apache/Express）提供 → 必须选
UTF-8 without BOM，避免 BOM 干扰 HTTP 头 - 用
file -i your.html（Linux/macOS）或 Notepad++ 的“编码”菜单 → 确认当前是否含 BOM；VS Code 右下角编码显示旁点开可切换
别信“UTF-8”和“UTF-8 with BOM”是同一回事——它们是两个不同编码选项，VS Code 默认新建文件是 without BOM，但旧文件重存时可能沿用原设置。
HTTP 响应头 Content-Type 和 <meta charset> 谁说了算？
当 HTML 通过 HTTP 协议传输（即网址以 http:// 或 https:// 开头），Content-Type: text/html; charset=UTF-8 响应头优先级高于 <meta charset>。也就是说，即使 HTML 里写的是 charset=GBK，只要响应头指定了 UTF-8，浏览器就用 UTF-8 解码。
但注意这些坑：
- Nginx 配置需在
server或location块中加charset utf-8;，不是charset UTF-8;（小写 utf-8 才被识别） - Apache 的
.htaccess中用AddDefaultCharset UTF-8，不能写成utf8或UTF_8 - Express 中不要只写
res.sendFile()，得显式设置：res.set('Content-Type', 'text/html; charset=utf-8') - 用 Chrome DevTools 的 Network 标签页 → 点 HTML 请求 → 查看 Response Headers → 确认
content-type值，这是真实生效的依据
为什么改了 <meta charset> 还是乱码？检查这三点
乱码不是单点问题，是整条链路的编码一致性断裂。只动 HTML 标签没用，必须同步确认：
- 源文件实际编码：VS Code 右下角显示 “UTF-8”，但右键“Save with Encoding”再选一次 UTF-8 才真正转码；若原文件是 GBK，仅改 meta 标签等于拿 UTF-8 解码器去读 GBK 字节，必然乱
-
外部资源编码：JS/CSS 文件本身也要存为 UTF-8（无 BOM），否则
alert("提交成功")里的中文在 JS 解析时报Uncaught SyntaxError: Invalid or unexpected token -
服务端输出逻辑：PHP/Python 拼接 HTML 时，若 PHP 文件自身是 GBK 编码，
echo "<meta charset=\"UTF-8\">"实际输出的是 GBK 字节流，浏览器收到的仍是乱码字节
最可靠的验证方式：打开 DevTools → Console 输入 document.characterSet，返回值必须是 "UTF-8"；再对比 Network 里的 Response Headers 和 Preview 页是否一致——不一致，说明服务端或网络层在中途改写了编码声明。
