仅告知浏览器用 UTF-8 解码文件，不改变实际编码；若文件非 UTF-8、HTTP 头冲突、BOM 干扰或位置靠后，均会导致乱码。
meta charset="UTF-8" 不会影响文件本身的字符集，它只是告诉浏览器“请用 UTF-8 解码这个文件”。如果文件实际不是 UTF-8 编码，加了这行反而更乱。
HTML 文件保存编码 ≠ meta charset 声明
浏览器看到 meta charset="UTF-8" 就按 UTF-8 解析字节流；但解析结果是否正确，完全取决于文件磁盘上存的是什么编码。常见错配：
- 编辑器保存为
GBK或Windows-1252，却写了meta charset="UTF-8"→ 中文变方块或问号 - 用记事本另存为
UTF-8，实际生成的是UTF-8-BOM（带 BOM 的 UTF-8），而某些旧工具或服务器会误判 BOM 为内容开头 → 渲染异常或 JS 报错 - 文件是纯 ASCII（只含英文、数字、标点），哪怕声明
UTF-8或ISO-8859-1都能显示正常 —— 因为 ASCII 是它们的子集
HTTP 响应头优先级高于 meta charset
当服务器返回的 HTTP 响应头中包含 Content-Type: text/html; charset=ISO-8859-1，浏览器会无视 meta charset，直接用 ISO-8859-1 解析。这意味着：
- 本地双击打开 HTML 文件时，没有 HTTP 头，才真正依赖
meta charset - 部署到 Nginx/Apache/Node.js 等服务器时，必须同步配置响应头：
res.setHeader('Content-Type', 'text/html; charset=utf-8') - Chrome DevTools 的 Network 标签页里看 Response Headers，确认
Content-Type字段值是否含charset=utf-8
meta charset 必须放在
浏览器从上到下解析 HTML，一旦遇到非 ASCII 字符（比如中文标题、emoji），又还没读到 meta charset，就会按默认编码（通常是系统 locale 或历史启发式猜测）尝试解码 —— 此时已发生的乱码无法回滚。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 必须紧贴
开始，前面不能有空格、注释、<script></script>或其他标签 - 错误写法：
<!-- 注释 --><meta charset="UTF-8">→ 注释导致延迟识别 - 更稳妥写法（HTML5 推荐）：
<meta charset="UTF-8">是内第一个元素，且不带http-equiv
BOM 是隐形干扰源，尤其在 JS/CSS 中
UTF-8-BOM（EF BB BF）虽不影响 HTML 主体渲染，但可能破坏其他环节：
- CSS 的
content: "编辑"出现多余空白或截断 → 因为 BOM 被当作不可见字符塞进字符串 - JS 文件以 UTF-8-BOM 开头，
console.log("测试")在某些环境报语法错误 → BOM 占据首字节，被误认为非法 token - 服务端模板（如 EJS、PHP）输出前若含 BOM，会导致
header()或setCookie失败 → HTTP 头已发送 - 解决方案：用 VS Code / Sublime Text / Notepad++ 显式选择 “UTF-8 without BOM” 保存
真正决定显示效果的，是三者一致：文件磁盘编码 + HTTP 响应头 charset + meta charset 声明。最容易被忽略的是编辑器保存时的隐式选项和 BOM 存在与否 —— 它们不会报错，但会让乱码问题变得难以复现和定位。
