UTF-8是现代网页唯一应选字符编码，必须在开头1024字节内用声明，且文件保存为UTF-8 without BOM；外部资源也须统一UTF-8编码。
UTF-8 是当前唯一应选的字符编码，不是“之一”，是事实标准。其他编码（如 GBK、ISO-8859-1）在现代网页中已无正当使用场景，强行用会导致乱码、截断、SEO 降权甚至 XSS 风险。
必须写在 <meta charset="UTF-8">
浏览器解析 HTML 是流式的，遇到第一个非 ASCII 字节就可能开始猜测编码。如果 <meta charset="UTF-8"> 不在 的前 1024 字节内（W3C 要求），旧版 Chrome、Firefox 会回退到系统默认编码，中文页面大概率出现“”或整段乱码。
- ✅ 正确位置：
<meta charset="UTF-8"> <title>...</title>—— 紧贴开始，前面不能有注释、空行或 JS - ❌ 错误写法：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这是 HTML4 写法，冗余且不被现代解析器优先识别 - ⚠️ 注意：即使服务端返回了
Content-Type: text/html; charset=utf-8，HTML 内仍需声明 —— 某些离线缓存、本地打开、或中间代理可能丢弃响应头
文件保存格式必须匹配声明
编辑器里选了 UTF-8，但若保存时带 BOM（Byte Order Mark），IE 和部分 Node.js 工具链会把 EF BB BF 当作不可见字符插在文档开头，直接导致 前移、触发怪异模式。
- ✅ 推荐保存为
UTF-8 without BOM（VS Code 默认、Sublime Text 可设、Notepad++ 需手动选） - ❌ 不要依赖“自动检测”：某些编辑器对混合编码文件会误判，尤其含英文引号、破折号、emoji 时
- ? 快速验证：用
file -i index.html（Linux/macOS）或十六进制查看器确认开头三字节不是EF BB BF
模板引擎和构建工具里的隐性陷阱
很多问题不是写错，而是被工具“悄悄覆盖”。例如：
立即学习“前端免费学习笔记（深入）”；
- Django 模板中，
{% load static %}后若未显式声明{% load i18n %}，多语言字符串可能被错误转义为 Latin-1 - Vite 或 Webpack 的
html-webpack-plugin若配置了minify: { removeComments: true }，可能删掉你放在顶部的<meta charset>注释说明（虽然不影响功能，但团队新人易误删） - PHP 文件若以
<?php开头且没加header('Content-Type: text/html; charset=utf-8');，Apache + mod_php 组合下可能沿用服务器默认编码
最常被忽略的一点：所有外部资源（CSS、JS、JSON、字体文件）也必须是 UTF-8 编码。一个 icon.css 里写了 content: "❤"; 却用 GBK 保存，整个伪元素就会渲染失败 —— 浏览器不会报错，只会静默跳过。
