HTTP响应头Content-Type优先于meta charset，动态网站必须在服务端显式设置charset=utf-8，否则即使meta写对也无效；浏览器解析顺序为：响应头→前1024字节meta→系统默认。
meta charset="UTF-8" 单独写在 HTML 里，对动态网站基本无效——浏览器早在收到第一个字节时就已决定用什么编码解码，此时服务端 HTTP 响应头还没发完，meta 根本来不及起作用。
HTTP 响应头中的 Content-Type 必须显式声明 charset
动态网站（PHP/Node.js/Python 等）生成 HTML 时，meta charset 是 fallback，不是主力。浏览器解析顺序是：先看 HTTP Content-Type 响应头 → 扫描前 1024 字节找 meta charset → 最后才用系统默认（如 Windows 的 GBK）。只要响应头没带 charset=utf-8，哪怕 meta 写得再标准，中文、emoji、特殊符号都可能乱码。
- PHP：在输出 HTML 前加
header('Content-Type: text/html; charset=utf-8');，且必须在任何echo或空白输出之前 - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=utf-8')要在res.send()或res.end()之前调用 - Python（Flask）：
return Response(html_content, mimetype='text/html; charset=utf-8')，不能只靠render_template自动推断 - Apache：.htaccess 中
AddDefaultCharset UTF-8仅对静态文件生效，动态脚本需自行设置响应头
模板引擎中 meta charset 必须写对位置，且不能依赖自动插入
很多模板（如 EJS、Jinja2、Vue SFC）支持自动注入 meta，但容易出错：比如插在 <title> 后、或被条件注释包裹、或在 <script> 标签之后。浏览器只扫描 <head> 开头约 1024 字节，一旦超限或位置偏移，meta charset 就被跳过。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须确保最终渲染出的 HTML 中，
<meta charset="UTF-8">是<head>内第一个非空格/换行/注释的标签 - 避免在
<meta charset>前写大段 JS 或内联样式（尤其是带中文注释的） - EJS 模板里别写成
<% if (lang === 'zh') { %><meta charset="UTF-8"><% } %>—— 条件逻辑会导致位置不可控 - Next.js / Nuxt 等 SSR 框架，
document.head.innerHTML动态插入无效，必须在服务端模板中硬编码
文件保存编码与响应头不一致时，乱码会“叠加发生”
常见组合错误：.php 文件本身是 GBK 编码，但响应头设了 charset=utf-8，结果浏览器用 UTF-8 解 GBK 字节流，一个中文变两个乱码；反过来，文件是 UTF-8，响应头却漏设或设成 gbk，也会崩。
立即学习“前端免费学习笔记（深入）”；
- 编辑器必须存为
UTF-8 without BOM（VS Code 默认就是；Notepad++ 要选 “UTF-8”，**不是** “UTF-8-BOM”） - Linux/macOS 下用
file -i your.php验证文件编码；Windows PowerShell 用Get-Content your.php -Encoding Byte | Select -First 3看开头是否为EF BB BF（BOM） - Chrome DevTools → Network → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type值是否含charset=utf-8 - 页面加载后，在 Console 执行
document.characterSet，返回值必须是"UTF-8"，否则说明某处没对上
最易被忽略的是：服务端代码里混用了不同编码的字符串拼接（比如从 GBK 数据库读数据 + UTF-8 模板），此时即使响应头和 meta 都正确，内容本身已是损坏字节流——这种乱码无法靠前端修复。
