失效主因是浏览器未正确读取该声明，常见于bom干扰、编码不匹配、响应头覆盖或标签位置错误；须确保文件真实为utf-8无bom、位于首行、http头明确指定charset=utf-8。
直接加 <meta charset="UTF-8"> 不一定管用，关键得看它有没有被浏览器真正读到、有没有被其他因素覆盖或干扰。
为什么 <meta charset="UTF-8"> 写了还是乱码
浏览器只扫描 HTML 文件开头约 1024 字节来查找 charset 声明。如果前面有 BOM、注释、空行、或者非 ASCII 字符（比如中文注释、全角空格），就可能跳过甚至误判这个 <meta> 标签。
-
<meta charset="utf8">或<meta charset="UTF8">是错的写法，必须是"UTF-8" - 标签不能写在
外面，也不能被注释包裹；最好放在的第一行，前面零个字符（包括空格、换行、BOM） - 如果文件本身不是 UTF-8 编码（比如保存成了 GBK 或 ANSI），那即使写了
<meta>，浏览器也会按系统默认编码（Windows 是 GBK）去读，结果就是“Ã¥”“é”这类乱码
如何确认 HTML 文件实际编码是否为 UTF-8
别只看编辑器右下角显示什么，要查真实字节。VS Code 显示 “UTF-8 with BOM” 就等于实际带了 BOM，而 BOM 会卡在 <meta> 前面，导致声明失效。
- 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 -Encoding Byte | Select -First 3，若前三字节是239 187 191，就是 BOM - VS Code 中：点击右下角编码名称 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM）→ 保存后状态栏应显示 “UTF-8”，且不带 “with BOM” 字样
HTTP 响应头比 <meta> 更优先
当页面通过 http:// 或 https:// 加载时，服务器返回的 Content-Type 响应头会直接覆盖 HTML 里的 <meta>。本地双击打开（file://）才只依赖 <meta>。
- Nginx 配置里写了
charset utf-8;，但没加add_header Content-Type "text/html; charset=utf-8";？那它不会自动给 HTML 加头，可能 fallback 到text/html; charset=iso-8859-1 - Express 中用了
res.sendFile()，默认不设 charset；必须手动加res.set("Content-Type", "text/html; charset=utf-8")，且要在sendFile()之前调用 - F12 打开 Network 面板，刷新页面，点 HTML 请求 → Headers → Response Headers → 看
Content-Type值是不是text/html; charset=utf-8
模板引擎和动态 HTML 容易漏掉编码控制
EJS、Thymeleaf、PHP 模板生成的 HTML，<meta charset> 可能被插在动态内容之后，或者服务端输出前悄悄加了 BOM（比如 PHP 文件开头有空白+<?php ）。
- PHP 文件本身不能有 BOM：用十六进制查看器检查开头三字节，或运行
hexdump -C file.php | head；BOM 存在会导致header()失效 - Node.js 的
res.send()如果传入字符串，需确保该字符串是 UTF-8 编码；若从文件读取，用fs.readFileSync(..., 'utf8')，别用Buffer默认方式 - 模板中不要把
<meta charset>放在<title></title>或<script></script>后面——它必须是下第一个可解析的标签
最常被忽略的是：BOM 和响应头冲突。一个带 BOM 的 UTF-8 文件 + 服务器返回 charset=gbk，浏览器会先按 gbk 解 BOM，再崩溃；这种组合下，删 BOM 和修响应头得一起做，单改一边没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
