乱码问题90%源于meta charset缺失、文件含BOM或HTTP响应头与meta冲突；需确保HTML无BOM、meta为head首个标签、响应头charset优先且统一设为UTF-8。
直接说结论：乱码问题 90% 出在 meta charset 缺失、文件实际编码含 BOM、或 HTTP 响应头与 meta 冲突这三处，不是浏览器问题，也不是“UTF-8 不行”，而是三者没对齐。
为什么 <meta charset="UTF-8"> 放在 <head> 开头还失效？
浏览器只扫描前 1024 字节找 meta charset，一旦开头有不可见字符（比如 BOM、空格、注释、换行），就可能跳过它，退回到系统默认编码（Windows 下常 fallback 到 GBK，Linux/macOS 常 fallback 到 ISO-8859-1）。
- 用
file -i index.html（macOS/Linux）或 PowerShell 中Get-Content index.html -Encoding Byte | Select -First 3检查是否含 BOM（输出ef bb bf就是） - VS Code 保存时务必选
UTF-8，不是UTF-8 with BOM；Sublime/Notepad++ 同理，状态栏必须显示 “UTF-8”，不能是 “UTF-8-BOM” 或 “UTF-8 with signature” -
<meta charset="UTF-8">必须是<head>里的第一个标签，前面不能有任何空格、<!-- -->注释、<script>或<link> - 如果用了构建工具（Vite/Webpack），确认 HTML 模板文件本身也是无 BOM 的 UTF-8，否则打包后仍带 BOM
HTTP 响应头 Content-Type 和 meta charset 谁说了算？
响应头优先级永远高于 meta。如果服务器返回 Content-Type: text/html; charset=gbk，哪怕你写了十遍 <meta charset="UTF-8">，浏览器也按 GBK 解析——meta 只是 fallback 机制。
- Nginx 配置中，确保
charset utf-8;写在http、server或至少location块里，且未被更细粒度的charset gbk;覆盖 - Apache 用
AddDefaultCharset UTF-8，避免.htaccess里残留AddDefaultCharset GB2312 - Node.js/Express 中，
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()之前调用；若用res.render()，模板引擎（如 EJS）可能已自动注入meta，但响应头仍需手动设 - 本地双击打开 HTML（
file://协议）时，没有 HTTP 响应头，此时完全依赖meta，所以更要保证它干净、靠前、无 BOM
外部 JS/CSS 文件也得统一 UTF-8，否则照样乱码
<script> 和 <style> 标签内联内容受页面编码影响，但外链的 .js 和 .css 文件有独立编码声明逻辑。如果它们本身是 GBK 编码却没声明，浏览器会按页面编码（UTF-8）去读 GBK 字节，结果就是 Uncaught SyntaxError: Invalid or unexpected token 或 CSS 中文注释变方块。
立即学习“前端免费学习笔记（深入）”；
- 所有
.js、.css文件必须用无 BOM 的 UTF-8 保存，和 HTML 一致 - 不要在
<script src="a.js" charset="UTF-8"></script>中写charset属性——HTML5 已废弃该用法，现代浏览器忽略它 - 如果 JS 里用
fetch()提交表单，记得设请求头：headers: {'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'}，否则后端收到的可能是乱码字节 - PHP/Python 等后端输出 HTML 前，先输出
header('Content-Type: text/html; charset=utf-8')，且确保 PHP 文件自身也是 UTF-8 无 BOM
最易被忽略的一点：编辑器保存编码和文件实际字节是两回事。VS Code 显示 “UTF-8” 只代表它“认为”是 UTF-8，不代表文件真没 BOM；而 file -i 或十六进制查看器才能看到真实字节。只要开头三个字节不是 ef bb bf，就说明没 BOM；只要它是，哪怕编辑器写着 “UTF-8”，也得重存。
