vs code右下角显示utf-8仅表示当前解码方式，非文件真实编码；应通过file -i（linux/macos）或powershell get-content -encoding byte（windows）验证实际编码及bom存在与否。
怎么看 HTML 文件实际保存的编码
VS Code 右下角显示的 UTF-8 只是当前打开方式，不是文件真实编码。很多乱码问题就卡在这儿：你看到的是 UTF-8，但文件其实是 GBK 存的。
验证方法：
- Linux/macOS：
file -i index.html看输出中的charset=值；再用head -c 4 index.html | xxd检查开头是否为ef bb bf（UTF-8 BOM） - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就有 BOM - Notepad++：菜单栏 → 编码 → 查看当前编码；再选“转为 UTF-8-BOM”并保存
怎么确认 <meta charset> 是否生效
浏览器只扫描前 1024 字节找 <meta charset>，而且必须是 ASCII 形式、不能被任何内容前置干扰。
常见失效场景：
-
开头有空格、换行、注释（<!-- -->）或 BOM 后紧跟<meta charset="UTF-8"> - 写了
<meta charset="utf8">或<meta charset="UTF8">—— 只有"UTF-8"是 HTML5 标准值 -
<meta charset>出现在<title></title>或<script></script>之后 —— 它必须是内第一个可执行标签
在 Chrome DevTools 的 Elements 面板里展开 ，确认 <meta charset="UTF-8"> 是第一个子节点。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
HTTP 响应头里的 Content-Type 怎么查
本地双击打开 HTML（file:// 协议）时，HTTP 头完全无效，只能靠 <meta charset> 和 BOM。只要走 HTTP（比如 Live Server、Nginx、Express），就必须检查响应头。
操作步骤：
- Chrome DevTools → Network → 刷新页面 → 点击 HTML 请求 → Headers → Response Headers → 找
Content-Type - 命令行快速验证：
curl -I http://localhost:5500/index.html，看返回里有没有charset=utf-8 - 如果值是
charset=gbk或压根没charset，那不管<meta>写得多标准，浏览器都按响应头优先级直接 fallback 到系统默认编码（Windows 是 GBK）
三者不一致时，浏览器到底听谁的
浏览器严格按固定顺序决定编码：HTTP 响应头 > <meta charset>（限前 1024 字节）> BOM > 系统默认编码（Windows GBK，Linux/macOS ISO-8859-1）。前一步能明确识别，后面全跳过。
最容易被忽略的坑：
- 用 VS Code Save with Encoding → UTF-8，但没勾选 “with BOM”，而服务器又没配
charset utf-8，此时若<meta>又因空格失效，就会 fallback 到 GBK —— 中文全变 - Live Server 默认加
Content-Type: text/html; charset=utf-8，但 Nginx/Apache/Express 若没显式配置，很可能发的是charset=iso-8859-1或干脆不带 charset - 服务端返回
Content-Type: text/html; charset=gbk，但 HTML 里写<meta charset="UTF-8">—— 浏览器以响应头为准，<meta>被无视，UTF-8 字节流用 GBK 解，必然乱码
真正要对齐的不是“看起来一样”，而是文件字节流、HTTP 头、<meta> 三者在各自生效条件下指向同一套编码规则。少一个环节，就可能在某个环境里突然崩掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
