必须位于最开头且文件为纯UTF-8编码，否则浏览器在前1024字节内无法识别，导致fallback至GBK/ISO-8859-1；HTTP响应头Content-Type优先级更高，BOM、编码不匹配、缓存未清均为常见乱码根源。
meta charset 必须写在 开头，且文件本身得是 UTF-8 编码，否则浏览器根本读不到它——这是绝大多数乱码问题的根源。
为什么 meta charset="UTF-8" 写了还是乱码
常见错误现象：HTML 里明明写了 <meta charset="UTF-8">，但中文仍显示为方块、问号或 符号。
- 文件实际保存为 GBK/ANSI/BOM-UTF-8，而
meta声明的是 UTF-8，字节流和声明不匹配 -
meta标签没放在最前面（比如插在<title></title>后面），浏览器只扫描前 1024 字节找 charset，可能跳过它 - 服务器返回了 HTTP 响应头
Content-Type: text/html; charset=GBK，它优先级高于meta，浏览器直接按 GBK 解码 - 用了
UTF-8 with BOM，BOM（EF BB BF）被某些工具误读为内容，导致解析偏移
VS Code 里怎么确保 HTML 文件是纯 UTF-8
VS Code 默认用 UTF-8，但打开旧文件时可能自动识别成 GBK，必须手动确认并转存。
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 右下角状态栏看当前编码（如显示
GBK或UTF-8 with BOM），点击它 - 选 “通过编码重新打开” →
GBK（如果原先是乱码），让内容正确显示 - 再点右下角，选 “以编码保存” →
UTF-8（注意：不要选UTF-8 with BOM） - 检查设置中
files.autoGuessEncoding设为true，files.encoding设为utf8，减少后续手动干预
HTTP 响应头比 meta 更优先
本地双击打开 HTML 时只依赖 meta 和文件编码；但通过 Web 服务器访问时，HTTP Content-Type 头决定第一解码方式。
立即学习“前端免费学习笔记（深入）”；
- Apache：在
.htaccess加AddDefaultCharset UTF-8 - Nginx：在
server或location块加charset utf-8; - Node.js/Express：响应前调用
res.setHeader('Content-Type', 'text/html; charset=UTF-8') - 验证方法：F12 → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers 中
Content-Type的charset值
表格、CSS、JS 文件也得统一用 UTF-8
<table> 本身不决定编码，但它里面的中文文本能否正常显示，取决于整个页面的解码逻辑是否一致。
<ul>
<li>CSS 文件若含中文注释或字体名，必须也保存为 UTF-8，并在 <code><link> 引入时确保服务器返回 charset=utf-8
<script></script> 中的字符串没问题；但外链 JS 若含中文，同样要 UTF-8 编码 + 正确响应头最容易被忽略的一点：改完 meta 和文件编码后，必须清空浏览器缓存再刷新——旧的缓存可能带着错误的编码信息，让你误以为修改没生效。
