必须紧贴开头且前面无任何字符（含bom、注释、空行），否则浏览器仅扫描前1024字节而跳过该标签，回落至系统默认编码（windows为gbk，linux/macos为iso-8859-1）导致乱码；同时http响应头content-type优先级高于meta标签，外部js/css文件也须统一为utf-8（无bom）。
<meta charset="UTF-8"> 必须放在 开头、且前面不能有任何字符（包括空格、换行、注释、BOM），否则大概率失效。
为什么 <meta charset="UTF-8"> 写了还是乱码
浏览器只扫描 HTML 文件前 1024 字节找 <meta charset>，一旦开头有 BOM（EF BB BF）、注释、空行或 <script></script> 标签，就会跳过它，回落到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1）。
常见错误现象：
- VS Code 状态栏显示 “UTF-8”，但保存时实际用了 “UTF-8 with BOM”
-
前有<!-- 注释 -->或空行 - 文件是 GBK 编码保存的，却硬写
<meta charset="UTF-8">
实操建议：
- 用
file -i filename.html（macOS/Linux）或Get-Content filename.html -Encoding Byte | Select -First 3（PowerShell）检查开头三字节是否为ef bb bf - 在 VS Code 中：先点右下角编码 → “Reopen with Encoding” → 选
GBK或ISO-8859-1看是否正常；确认后点 “Save with Encoding” → 选UTF-8（不是 “UTF-8 with BOM”） - Notepad++：编码 → 转为 UTF-8（无 BOM）
HTTP 响应头 Content-Type 比 <meta> 更优先
如果服务器返回的 HTTP 响应头里有 Content-Type: text/html; charset=gbk，哪怕 HTML 里写了 <meta charset="UTF-8">，浏览器也按响应头执行 —— <meta> 只是 fallback。
实操建议：
- Chrome DevTools → Network → 刷页面 → 点 HTML 请求 → Headers → Response Headers → 查看
Content-Type - Nginx 配置中加
charset utf-8;（注意小写，不能写charset=UTF-8;） - Apache 配置中用
AddDefaultCharset UTF-8（不能写UTF8或utf-8） - Express 中显式设置：
res.set('Content-Type', 'text/html; charset=utf-8')
外部 JS/CSS/JSON 文件也要统一 UTF-8
HTML 页面本身没问题，但引入的 <script src="app.js"></script> 或 <link rel="stylesheet" href="style.css"> 如果是 GBK 编码保存，依然会触发乱码或 Uncaught SyntaxError: Invalid or unexpected token（尤其含中文或 emoji 时）。
实操建议：
- 所有 .js、.css、.json 文件都用 UTF-8（无 BOM）保存
- 不依赖
charset属性：<script src="a.js" charset="UTF-8"></script>已废弃，且多数现代浏览器忽略它 - 用
curl -I http://yoursite.com/a.js检查响应头是否含charset=utf-8
BOM 是最隐蔽的坑：它看不见，却让 <meta charset> 彻底失效；而 HTTP 响应头和外部资源编码不一致，会让问题看起来“时好时坏”。处理顺序应该是：先验文件真实编码 → 清 BOM → 统一存为 UTF-8（无 BOM）→ 检查服务端响应头 → 最后核对外部资源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
