<meta charset="UTF-8">必须放在<head>内最前面，紧贴<head>标签后，以避免非ASCII字符按默认编码解析导致乱码；应选UTF-8而非GBK或ISO-8859-1，因其兼容全部Unicode字符且为Web事实标准；编辑器需保存为UTF-8无BOM，服务端响应头charset须与之统一。
HTML页面里该放在哪儿
必须放在 <head> 内，且越靠前越好——最好紧贴 <head> 开始标签之后。浏览器解析到它之前读到的字节，如果含非ASCII字符（比如中文标题、注释里的“测试”），就可能按默认编码（通常是ISO-8859-1）解码，导致乱码已发生，后面再声明也救不回来。
常见错误是把它塞在 <title> 后面，或者和 <meta name="viewport"> 混在一起没注意顺序。
- ✅ 正确位置：
<head> <meta charset="UTF-8"> <title>活动页</title> <meta name="viewport" content="width=device-width"> </head>
- ❌ 错误示例：
<head> <title>活动页</title> <meta charset="UTF-8"> <!-- 太晚了，title里的中文可能已乱码 --> </head>
为什么选UTF-8而不是GBK或ISO-8859-1
UTF-8 是当前 Web 事实标准，兼容所有 Unicode 字符，包括 emoji、繁体字、日文假名、数学符号等；而 GBK 只支持简体中文及部分扩展，ISO-8859-1 根本不支持中文。用错编码，轻则标题显示为“活动页”，重则表单提交时后端收到乱码参数。
另外，现代构建工具（Vite、Webpack）、CDN 和 HTTP 响应头（Content-Type: text/html; charset=UTF-8）默认都倾向 UTF-8，保持一致能避免 header 与 meta 冲突。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 服务端返回的
Content-Type响应头若指定charset=GBK，但 HTML 里写charset="UTF-8"，以响应头为准——这时必须统一改服务端配置或 Nginx 的charset指令 - 纯静态 HTML 文件（无服务器）完全依赖
<meta charset>，务必写对
编辑器保存编码也要同步设成UTF-8无BOM
即使写了 <meta charset="UTF-8">，如果文本编辑器（如 VS Code、Sublime、记事本）把文件存成了 UTF-8 with BOM，某些老版本 IE 或部分 Node.js 工具会把 BOM（\uFEFF）当内容开头，导致空白行、CSS/JS 解析失败，甚至 <meta> 被挤到第二行而失效。
- VS Code：右下角点击编码名称 → 选 “Save with Encoding” → 选 “UTF-8”（不是 “UTF-8 with BOM”）
- 记事本：另存为 → 编码选 “UTF-8”（Windows 10/11 默认已是，旧版可能默认 ANSI）
- 可通过命令行快速验证：
file -i your-page.html（Linux/macOS）或用 hex editor 看前3字节是否为ef bb bf（BOM）
移动端微信/QQ内置浏览器特别要注意
微信 Android 客户端曾长期存在一个 bug：如果 <meta charset> 不在前1024字节内，就忽略它，强行按 GBK 解析——哪怕你写了 UTF-8 也没用。虽然新版已修复，但存量低端机或旧版本仍可能触发。
所以除了位置靠前，还要避免在 <head> 顶部加大量注释、空格或广告 JS 注入代码。
- 删掉
<head>里所有无意义的空行和长注释 - 不要在
<meta charset>前插入第三方统计脚本（比如早期友盟、百度统计的同步加载方式） - 如果用了模板引擎（如 EJS、Pug），确认生成后的 HTML 中
<meta charset>确实位于最前面
实际部署时，最易被忽略的是编辑器保存编码与 HTML 声明不一致，以及服务端响应头覆盖了 meta 设置——这两点一出问题，连刷新都看不到效果。
