生效需三者同时满足：文件实际为utf-8无bom编码、http响应头未指定charset、且该标签位于开头1024字节内；任一缺失即触发系统默认编码（如windows的gbk），导致乱码。
meta charset 生效的前提是：文件本身是 UTF-8 编码，且没 BOM；HTTP 响应头没覆盖它；它还得出现在 开头 1024 字节内。三者缺一，meta charset="UTF-8" 就可能失效，浏览器 fallback 到系统默认（Windows 是 GBK），直接显示乱码。
为什么 meta charset="UTF-8" 写了还是乱码
常见现象：VS Code 显示“UTF-8”，但打开 HTML 文件仍是乱码；F12 Network 里 Response Headers 的 Content-Type 是 text/html; charset=gbk 或 iso-8859-1；或者本地双击打开（file:// 协议）时完全不认 meta。
-
meta charset只在 HTTP 响应头没指定 charset 时才起作用；一旦响应头含Content-Type: text/html; charset=xxx，浏览器就直接按那个解码，meta被忽略 - 如果文件实际是 GBK 编码，却写了
meta charset="UTF-8"，浏览器硬用 UTF-8 解 GBK 字节流，必然乱码 - BOM（
EF BB BF）出现在meta标签之前，会干扰浏览器对前 1024 字节的扫描，导致 charset 声明被跳过 - 本地
file://打开时没有 HTTP 响应头，全靠meta，但若文件带 BOM 或meta不在最前面，依然失效
怎么确认 HTML 文件真实编码
别信编辑器右下角的状态栏——它只显示“当前认为的编码”，不是文件真实字节。得看原始字节：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- Linux/macOS：
file -i filename.html或head -c 4 filename.html | xxd，输出含ef bb bf表示有 UTF-8 BOM - Windows PowerShell：
Get-Content filename.html -Encoding Byte | Select -First 3，结果为239 187 191即 BOM - VS Code：若状态栏显示 “UTF-8 with BOM”，点它 → “Save with Encoding” → 选 “UTF-8”（不含 BOM）再保存
- Notepad++：菜单栏“编码” → 看当前是 “UTF-8-BOM” 还是 “UTF-8”，选“转为 UTF-8 编码”再保存
Web 服务器必须发正确的 Content-Type 响应头
开发时用 file:// 打开容易掩盖问题，真正上线必须走 HTTP。此时 meta charset 是 fallback，响应头才是权威：
- Nginx：
charset utf-8;（写在http、server或location块里），注意不是UTF-8大写 - Apache：
AddDefaultCharset UTF-8（写在.htaccess或主配置） - Node.js/Express：
res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()之前调用 - PHP：
header("Content-Type: text/html; charset=utf-8");必须在任何输出（包括空格、BOM）之前执行
容易被忽略的细节
最常踩的坑不在 meta 本身，而在它周围：
-
开头不能有任何空格、换行、注释或 BOM ——meta必须是第一个标签 - 别写
<meta charset="utf8">（少个横杠）或<meta charset="UTF8">（缺横杠且大小写错），标准只认UTF-8 - 外部资源如
<script src="app.js"></script>，JS 文件自身也必须是 UTF-8 编码，否则中文字符串照样乱 - 用
fetch()加载 HTML 片段时，响应头若没charset=utf-8，response.text()可能按 ISO-8859-1 解，得用response.arrayBuffer()+new TextDecoder('utf-8')显式解码
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
