<meta charset="UTF-8">必须置于<head>内最前端，紧随<!DOCTYPE html>和<html>之后、<title>之前，且前方不能有任何字符（包括空格、注释、BOM），否则浏览器在解析前1024字节时可能无法识别，回退至系统默认编码（如GBK）导致顶部中文乱码；同时需确保文件实际保存为UTF-8无BOM、HTTP响应头Content-Type中charset一致。
meta charset 必须放在 最前面
浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），就会回溯查找 meta charset 声明；如果它出现在 <title> 或其他标签后面，可能导致前几个字符乱码。常见现象是页面顶部出现“”或方块，尤其在服务端未发送 Content-Type 头的情况下。
正确写法只有一种主流形式：
<head> <meta charset="UTF-8"> <title>我的页面</title> <meta name="description" content="..."> </head>
-
charset属性值不区分大小写，但惯例全大写UTF-8 - 不要写成
charset=utf8（缺短横线）或charset=UTF8（标准写法要求带短横线） - 不能写多个
meta charset，否则浏览器可能忽略全部或行为未定义 - 服务端
Content-Type: text/html; charset=UTF-8与前端meta charset冲突时，以 HTTP 头为准——但开发阶段常无头，所以meta不可省
为什么不用 http-equiv="Content-Type"？
老式写法 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 理论上等效，但实际有坑：
- 部分旧浏览器（如 IE8 及更早）对
http-equiv解析延迟，仍可能触发乱码 - HTML5 明确推荐简写
charset属性，语义更直接、解析更快 - 某些构建工具（如 Webpack + html-webpack-plugin）会自动注入
meta charset，若你再手动加一条http-equiv版本，反而造成冗余甚至冲突
声明了 UTF-8，但还是乱码？检查这三点
声明只是第一步，真正生效依赖三者一致：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 文件本身保存编码必须是
UTF-8（无 BOM）。用 VS Code、Sublime 或 Notepad++ 打开文件，确认右下角显示 “UTF-8” 而非 “UTF-8 with BOM” 或 “GBK” - 服务器返回的 HTTP 响应头中，
Content-Type的charset参数要匹配，例如Content-Type: text/html; charset=UTF-8。本地双击打开file://协议时无响应头，全靠meta；部署后务必用浏览器开发者工具的 Network 面板看 Headers - 如果页面含动态 JS 插入内容（如
document.write或 innerHTML），且 JS 文件本身不是 UTF-8 编码，也会导致插入的中文乱码——此时需单独给<script>加charset="UTF-8"属性
移动端和 SEO 对 charset 的隐性要求
Google 和百度爬虫都依赖正确编码解析文本。如果 meta charset 缺失或错位，可能导致：
- 标题、描述抓取失败，搜索结果中显示乱码或截断
- iOS Safari 在某些网络环境下（如运营商代理）更严格依赖
meta，缺失时直接渲染为空白或报错 - 微信内置浏览器对
UTF-8 with BOM文件极其敏感，哪怕meta正确，BOM 也会让首行 JS 报语法错误
最稳妥的做法：所有 HTML 文件用编辑器另存为 “UTF-8 无 BOM”，开头第一行就是 <!DOCTYPE html>，第二行就是 <html>，第三行就是 <head><meta charset="UTF-8">——中间不空行、不注释、不 script。
