<meta charset="UTF-8">必须置于<head>最开头、任何非ASCII内容（如BOM、注释、<title>）之前，否则浏览器在前1024字节内无法识别而fallback至ISO-8859-1或GBK，导致乱码或“Invalid or unexpected token”错误。
meta charset 必须放在 <head> 开头、任何非 ASCII 内容（比如 <title>、注释、BOM）之前，否则浏览器大概率 fallback 到 ISO-8859-1 或 GBK，直接显示乱码或报 Invalid or unexpected token。
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只扫描 HTML 文件开头 1024 字节，且只认其中纯 ASCII 范围内的 <meta charset>；一旦前面有 BOM（EF BB BF）、中文 <title>、HTML 注释或空行，它就跳过不识别。
-
<head><title>你好</title><meta charset="UTF-8"></head>→ 失效：title 中文超出 ASCII 范围 -
<head><!-- 注释 --><meta charset="UTF-8"></head>→ 失效：注释含 ASCII 以外字符（如中文） -
<head><meta charset="utf8"></head>→ 失效：utf8不是 IANA 标准值，应为UTF-8 - VS Code 里选 “UTF-8 with BOM” 保存 → 失效：BOM 占前 3 字节，导致 meta 扫描失败
怎么验证文件实际编码和 BOM 是否存在
别信编辑器右下角显示的“UTF-8”，要查真实字节：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- macOS/Linux：
file -i index.html看 MIME 类型；head -c 4 index.html | xxd查前 4 字节，ef bb bf表示有 BOM - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，输出239, 187, 191就是 BOM - VS Code：用 “Reopen with Encoding” 强制以 GBK 打开，如果中文正常显示，说明原文件其实是 GBK 编码
HTTP 响应头比 meta 更优先，但本地双击打开时它不存在
服务器返回的 Content-Type: text/html; charset=utf-8 会覆盖 meta 声明；但 file:// 协议下 HTTP 头为空，此时全靠 meta 和文件实际编码匹配。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置加
charset utf-8;；Apache 加AddDefaultCharset UTF-8 - Node.js Express 不要只写
res.sendFile()，补上res.set('Content-Type', 'text/html; charset=utf-8') - 本地开发时，若用 Live Server 插件，它默认加了正确响应头；但直接双击 HTML 文件，就完全依赖
<meta charset="UTF-8">的位置和文件真实编码
最常被忽略的一点：改了 meta 标签但没重存文件，或者存成了 GBK 编码却还写着 UTF-8 —— 浏览器看到声明和字节对不上，就会按自己的规则硬猜，结果几乎总是错的。
