必须置于最开头、任何非ASCII字符（含、注释、BOM、空格、emoji）之前，否则浏览器仅扫描前1024字节且只识别ASCII范围内的meta标签，一旦遇到非ASCII内容即跳过该声明，fallback至系统默认编码（Windows为GBK，macOS/Linux为ISO-8859-1），导致中文乱码、emoji异常、JS语法错误等问题。

meta charset="UTF-8" 必须放在 开头、任何非 ASCII 字符（包括 、注释、BOM、空格、emoji）之前，否则浏览器可能 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），直接导致中文乱码。

为什么 meta charset="UTF-8" 放错位置就失效

浏览器解析 HTML 时，只扫描前 1024 字节，并且只识别 ASCII 范围内的字符来匹配 meta charset。一旦在这段范围内出现非 ASCII 字符（比如中文 、注释 、BOM \uFEFF 或换行后缩进空格），就会跳过该标签，转而用系统默认编码加载整页。

• → 失效（ 含中文，已超 ASCII）
• → 失效（注释不是 ASCII）
• \n → 失效（换行+空格虽是 ASCII，但某些旧 WebView 会误判）
• ✅ 正确：

charset 的值必须严格写成 "UTF-8"

IANA 官方注册名只认 UTF-8（U/T/F 大写，8 是数字，中间短横不可省略）。写成 "utf8"、"utf_8"、"UTF8" 或 "unicode" 在部分环境（如 Safari WebView、html-webpack-plugin、某些嵌入式浏览器）中会被忽略，退回到 fallback 编码。

• ❌ —— Chrome 可能容忍，但不保证
• ❌ —— 缺短横，非标准
• ✅ —— 唯一推荐写法

文件保存编码必须和 meta 声明一致

VS Code 默认新建文件是 UTF-8，但打开一个 GBK 编码的旧文件后，再保存，很可能仍存为 GBK —— 此时即使写了 meta charset="UTF-8"，浏览器也会把 GBK 字节流当 UTF-8 解，每个中文变两个乱码字（如 “你好” 显示为 “浣犲ソ”）。

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

• VS Code：用 File → Save with Encoding → UTF-8（注意：不要选 “UTF-8 with BOM”，BOM 会出现在 前，干扰解析）
• 验证方法：file -i index.html（Linux/macOS）或 PowerShell 中 Get-Content index.html -Encoding Byte | Select -First 3，确认输出不含 ef bb bf
• 别依赖编辑器自动识别：Sublime/Notepad++ 有时会误判 GBK 文件为 UTF-8，手动指定编码再重开更可靠

HTTP 响应头比 meta 更优先，但别指望它兜底

如果服务器返回 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了 meta charset="UTF-8"，浏览器也以响应头为准 —— 这是规范行为，不是 bug。

• Nginx 配置：在 server 或 location 块加 charset utf-8;
• Express：用 res.set('Content-Type', 'text/html; charset=UTF-8')
• 静态托管（Vercel/GitHub Pages）：默认发 UTF-8，但前提是你的文件本身是 UTF-8 编码
• ⚠️ 关键点：响应头和 meta、文件实际编码三者必须完全一致，缺一不可

BOM 是最隐蔽的坑：它藏在文件开头、看不见，却能让 meta charset 彻底失效；而编辑器里“UTF-8 with BOM”的选项，恰恰是多数人踩坑的第一步。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！