必须紧贴开头，因为浏览器仅扫描前1024字节查找该标签；若其前存在空格、换行、注释或bom，将导致声明失效而回退至系统默认编码（如windows的gbk），引发中文乱码。
为什么 <meta charset="UTF-8"> 必须紧贴
浏览器解析 HTML 时，只扫描前 1024 字节来查找 <meta charset>；如果它前面有空格、换行、注释或 BOM，就可能被跳过，直接 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1），结果就是中文显示为 或乱码符号。
如何检查并修复 <meta charset="UTF-8"> 的位置问题？
先确认实际文件结构是否合规：
- 用 VS Code 打开 HTML 文件，看状态栏右下角是否显示
UTF-8（不是UTF-8 with BOM）；若显示GBK或ISO-8859-1，说明文件本身不是 UTF-8 编码 - 把光标移到
标签后，按 Ctrl+Shift+P（Mac 是 Cmd+Shift+P），运行Reopen with Encoding→ 选UTF-8，再Save with Encoding→ 选UTF-8（注意：不要选UTF-8 with BOM） - 手动检查源码：
后必须**立刻**是<meta charset="UTF-8">，中间不能有任何字符——包括空格、换行、<!-- 注释 -->、<script></script>或 BOM 字节
常见干扰项：BOM、注释、空行怎么排查？
BOM 是隐形杀手，尤其在 Windows 下用记事本保存过或 VS Code 默认带 BOM 时：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- Linux/macOS：运行
head -c 4 index.html | xxd，输出ef bb bf表示存在 BOM；用sed -i '1s/^\xEF\xBB\xBF//' index.html删除 - Windows PowerShell：运行
(Get-Content index.html -Raw).Length -gt 0 -and (Get-Content index.html -Encoding Byte)[0..2] -eq 239,187,191，返回True即含 BOM；用Set-Content index.html -Value (Get-Content index.html -Raw) -Encoding UTF8重写（自动去 BOM） - VS Code 中，若状态栏显示
UTF-8 with BOM，点它 →Save with Encoding→ 选UTF-8（不带 BOM） - 删掉
和<meta charset="UTF-8">之间所有内容，包括空行和<!-- ... -->
HTTP 响应头和 meta 标签冲突时谁生效？
HTTP 响应头里的 Content-Type: text/html; charset=utf-8 优先级高于 <meta charset>；但如果响应头没声明 charset（比如本地双击打开 file://），或者值是 charset=gbk，那 <meta charset="UTF-8"> 就会被忽略——此时乱码跟位置无关，而是服务端配置问题。
- F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查看
Content-Type是否含charset=utf-8（注意小写、等号前后无空格） - Nginx 配置里加
add_header Content-Type "text/html; charset=utf-8";（放在 location 块内） - Express 中用
res.set("Content-Type", "text/html; charset=utf-8")，且必须在res.send()之前调用 - PHP 中用
header("Content-Type: text/html; charset=utf-8");，且必须在任何输出（包括空白、<?php前空行）之前执行
真正容易被忽略的是：文件编码、BOM、HTTP 头、meta 位置这四者必须全部对齐。少一个，就可能在某台机器、某个浏览器、某种访问方式下出乱码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
