<meta charset="UTF-8">必须置于<head>第一个子元素位置，因浏览器仅扫描前1024字节且遇BOM、空格、注释等即失效，导致fallback至GBK等默认编码引发乱码。
<meta charset="UTF-8"> 必须放在 <head> 开头、且是第一个子元素，否则浏览器可能根本读不到它——90% 的中文乱码问题都出在这一步。
为什么 <meta charset="UTF-8"> 放错位置就失效
浏览器只扫描 HTML 文件前 1024 字节来查找 <meta charset>，一旦开头有不可见字符（比如 BOM、空格、换行、HTML 注释 <!-- --> 或 <script> 标签），就会跳过或误判。
- 常见错误现象：页面显示 “” 或方块，F12 查看 Network → Response Headers 中
Content-Type是text/html; charset=gbk或缺失 charset - 真实场景：VS Code 默认保存为 UTF-8 with BOM，但 BOM（
ef bb bf）会卡在文件最前面，导致<meta charset>实际排第二 - 验证方法：
xxd -l 4 index.html（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），输出含ef bb bf就说明有 BOM - 解决办法：用编辑器“另存为”，选
UTF-8（不是UTF-8 with BOM）；VS Code 右下角状态栏点击编码 → “Reopen with Encoding” → 选UTF-8，再 “Save with Encoding” → 选UTF-8
HTTP 响应头和 meta charset 谁优先
HTTP 响应头中的 Content-Type: text/html; charset=utf-8 永远比 <meta charset> 优先级高；但若响应头没设 charset（或设成 gbk），浏览器才 fallback 到 meta 标签。
- 常见错误现象：本地双击打开
file://页面正常，但部署到 Nginx 后乱码——因为 Nginx 默认不发 charset，fallback 到系统默认（Windows 是 GBK） - Nginx 配置必须加：
charset utf-8;（小写，不能写charset=UTF-8），放在http、server或location块里 - Apache 配置写：
AddDefaultCharset UTF-8（注意大小写，不能写utf8） - Express.js 中必须在
res.send()或res.render()前调用：res.set('Content-Type', 'text/html; charset=utf-8')
外部 JS/CSS 文件也得统一 UTF-8
HTML 本身没问题，但引入的 <script src="app.js"> 或 <link rel="stylesheet" href="style.css"> 如果是 GBK 编码，浏览器仍会报 Uncaught SyntaxError: Invalid or unexpected token 或 CSS 注释乱码。
立即学习“前端免费学习笔记（深入）”；
- 验证方法：用
file -i app.js看编码；或直接用文本编辑器打开，确认右下角显示 “UTF-8”（不是 “GBK” 或 “ANSI”） - JS 文件无需
@charset；CSS 文件第一行可加@charset "UTF-8";，但必须紧贴开头、前面不能有任何字符（包括 BOM 和空格） - Webpack/Vite 等构建工具默认输出 UTF-8，但若源文件是 GBK，需在 loader 中指定 encoding（如
raw-loader?encoding=GBK再转） - 特别注意：PHP 模板中如果 PHP 文件头部有 BOM，
header()会失效，导致 HTTP 响应头漏掉 charset
真正容易被忽略的是：BOM 不仅影响 HTML，还会让 JS/CSS 解析失败；而 HTTP 响应头和 meta 标签不是“二选一”，是“主备关系”——线上环境永远要以响应头为准，meta 只是兜底。别信“写了 meta 就万事大吉”。
