必须置于最开头，因浏览器解析HTML时会提前扫描前1024字节确定编码，若延迟声明，中文、emoji等非ASCII字符将按默认编码（如GBK或ISO-8859-1）错误解码，导致乱码、DOM异常及脚本错误。
必须写，而且要写在 最靠前的位置——不是“建议”，是防止乱码的底线操作。浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、emoji、特殊符号），又没及时拿到编码声明，就会按系统默认编码（如 Windows 的 GBK）瞎猜，结果就是“你好”变“浣犲ソ”。
为什么
浏览器从上到下解析 HTML，字符集声明越晚出现，前面已读入的内容就可能被错误解码。哪怕只差几行，都可能导致
- 必须出现在所有其他
标签之前（包括viewport、description等） - 必须在
- 必须在任何外部 CSS/JS 加载前（虽然不影响加载，但影响页面初始渲染文本）
- 不能依赖 HTTP 响应头
Content-Type: text/html; charset=utf-8替代——如果服务端没配或配错，就是最后一道防线
HTML5 只认 这一种简写。旧写法 虽然仍能被部分浏览器识别，但语义不清晰、冗长，且在某些解析器中优先级低于新写法。
- 新写法是 HTML5 标准语法，解析更稳定
- 大小写不敏感，但推荐统一用大写
UTF-8（和 IANA 注册名一致） - 不要写成
utf8或utf_8——某些老工具或校验器会报错 - 不要加空格：
charset=" UTF-8 "是无效的
文件保存编码必须和
声明只是告诉浏览器“怎么读”，实际文件内容得真按这个编码存。编辑器里存成 GBK，却声明 UTF-8，照样乱码。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用 VS Code、Sublime、WebStorm 等现代编辑器时，右下角查看当前编码，手动选 “Save with Encoding → UTF-8”
- 避免用记事本保存 HTML——它默认用系统编码（Windows 是 GBK），极易踩坑
- 检查命令行下文件编码：
file -i your-page.html（Linux/macOS）或用 PowerShell：Get-Content your-page.html -Encoding UTF8测试是否能正常读取 - 如果已有乱码文件，不要直接复制粘贴修复——先用正确编码重新打开，再另存为 UTF-8
HTTP 响应头和 meta 标签冲突时谁生效
HTTP 响应头中的 Content-Type: text/html; charset=iso-8859-1 会覆盖 ，浏览器以响应头为准。这是硬性规则，不是 bug。
- 本地双击打开 HTML 文件（
file://协议）时，没有 HTTP 头，完全依赖 - 开发时用 live server 或 Python 的
python -m http.server，默认不带 charset，所以生效 - 上线后若发现乱码，先用 Chrome DevTools 的 Network 面板看响应头里的
Content-Type字段，再比对 Elements 面板里的是否一致 - Nginx/Apache 配置中显式设置
AddDefaultCharset utf-8或charset UTF-8;可避免服务端覆盖
最容易被忽略的一点：即使页面全是英文，只要用了 emoji、版权符号 ©、数学符号 ∑，或者未来某天加了中文注释，没声明 UTF-8 就等于埋雷。这不是“等出问题再改”的事情，是创建 HTML 文件第一秒就要做的动作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
