<meta charset="UTF-8">必须位于<head>最开头、任何其他标签（含<title>、注释、空格）之前，文件须为无BOM的UTF-8编码，且服务器响应头Content-Type必须包含charset=utf-8，三者缺一中文即显“锟斤拷”。
直接说结论：<meta charset="UTF-8"> 必须出现在 <head> 最开头、任何其他标签（包括 <title>、<script>、注释、空格）之前，且文件本身必须是无 BOM 的 UTF-8 编码，服务器响应头 Content-Type 也得带 charset=utf-8 —— 少一个，中文就可能变“锟斤拷”。
为什么 <meta charset> 放错位置会失效
浏览器解析 HTML 时，只扫描前 1024 字节找 <meta charset>；一旦遇到非空白、非注释的字符（比如 <title>、<script>、甚至一个中文空格或 <!-- -->），就立刻停止查找， fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 常是 ISO-8859-1）。
-
<meta charset="UTF-8">必须是<head>内第一个可渲染内容，前面只能有空白符（\n、\t、 - 写成
<meta\ncharset="UTF-8">或换行缩进后带空格，某些旧解析器会识别失败 -
<meta http-equiv="content-type" content="text/html; charset=UTF-8">是 HTML4 兼容写法，但现代浏览器优先认charset属性，没必要用
VS Code 保存时怎么避免 BOM 陷阱
VS Code 右下角显示 “UTF-8”，不等于真的干净 —— 它默认可能存成 “UTF-8 with BOM”。BOM（EF BB BF）在 HTML 开头是非法字节，会导致：<!DOCTYPE html> 被当成文本内容、微信公众号上传失败、Node.js res.setHeader() 报错 “Cannot set headers after they are sent”。
- 保存时点右下角编码 → Save with Encoding → 选
UTF-8（明确不含 “with BOM” 字样） - 验证命令：
xxd -l 4 yourfile.html，输出第一行不含ef bb bf才算合格 - Notepad++ 用户：菜单栏 编码 → 转为 UTF-8 无 BOM，别选 “UTF-8-BOM”
服务器响应头和本地文件必须一致
即使 <meta charset> 写对、文件也是 UTF-8，如果服务器发来的 HTTP 响应头是 Content-Type: text/html; charset=GBK，浏览器会直接忽略 <meta>，强制用 GBK 解析 —— 结果就是整页乱码，且 document.characterSet 在控制台里返回 "GBK"。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置：在
server或location块中加charset utf-8;（注意小写，不能写UTF-8） - Apache：在
.htaccess或httpd.conf加AddDefaultCharset UTF-8 - Node.js/Express：在
res.send()前手动设头：res.set('Content-Type', 'text/html; charset=utf-8') - 本地双击打开（
file://协议）：HTTP 头不存在，完全依赖<meta>和文件编码，此时 BOM 和位置错误最致命
检查是否真生效的三步验证法
别信编辑器右下角、别信浏览器地址栏图标、别信自己“应该没问题”——只有这三步全过，才算真正稳了。
- DevTools → Network → 刷新 → 点 HTML 请求 → Response Headers → 确认
Content-Type含charset=utf-8 - 同个请求 → Preview 或 Response 标签页 → 直接看原始字节渲染：开头没
、没 “锟斤拷”，中文清晰可读 - Console 里输
document.characterSet→ 返回"UTF-8"，且document.inputEncoding也一致
最容易被跳过的其实是文件编码本身 —— 很多人改了 <meta>、配了服务器，却忘了 Notepad++ 里点错了一次“转为 UTF-8-BOM”，或者从 Word 复制粘贴进去了隐藏格式符号。真实环境里，BOM 和开头空格比语法错误更难排查。
