<meta charset="UTF-8">必须置于<head>最开头且在前1024字节内，否则浏览器扫描不到而fallback至系统默认编码（Windows为GBK，Linux/macOS为ISO-8859-1），导致中文乱码；其失效主因是BOM、注释、空格或<script>等前置内容阻断扫描。
meta charset="UTF-8" 必须出现在 <head> 开头 1024 字节内，否则浏览器会 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1），中文直接变问号或乱码。
为什么 meta charset 放错位置就失效
浏览器解析 HTML 时只扫描前 1024 字节找 meta charset；如果这范围内有 BOM（ef bb bf）、注释、空格、<script> 或 <title> 标签挡在前面，它就根本看不到这个声明。
- VS Code 默认保存为 UTF-8 without BOM，安全；选 “UTF-8 with BOM” 反而会让
meta被挤到第 4 字节之后，直接失效 -
<!-- 注释 -->算字符，哪怕写在<head>里，只要它在meta前面，就占字节数 -
<meta charset="utf8">或<meta charset="UTF8">不被标准认可，部分 CI 工具或 WebView 会报错或 fallback
怎么验证文件实际编码是否匹配 meta
光写 <meta charset="UTF-8"> 没用 —— 如果文件本身是 GBK 编码存的，浏览器按 UTF-8 解，每个中文都会解成两三个乱码字符。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- Linux/macOS：运行
file -i index.html，看输出是不是charset=utf-8 - PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就带 BOM；不是就大概率没 BOM - VS Code 底部状态栏显示 “UTF-8” 仅代表当前打开方式，不等于文件真实编码；要先点 “Reopen with Encoding” 试 GBK，能正常显示说明原文件是 GBK
HTTP 响应头比 meta 优先级更高
当页面通过 HTTP 加载（比如 http://localhost），服务器返回的 Content-Type: text/html; charset=gbk 会直接覆盖 HTML 里的 meta charset="UTF-8"，结果还是乱码。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置里写
charset utf-8;（小写，不能写charset=UTF-8） - Apache 的
.htaccess写AddDefaultCharset UTF-8（大小写敏感，不能写utf8） - Express.js 中用
res.set('Content-Type', 'text/html; charset=utf-8')，注意这里utf-8小写才稳妥 - GitHub Pages、Vercel 这类托管服务默认发 UTF-8 响应头，不用额外配；但本地双击打开
file://协议时，HTTP 头不存在，全靠meta和文件编码
最容易被忽略的是：改完 meta 后没重新保存文件为 UTF-8，或者改了响应头但忘了重启服务。这两步漏掉一个，前面所有操作都白做。
