先查Network中Response Headers的Content-Type是否含charset=utf-8；若否，则meta被无视；若是，再确认<meta charset="UTF-8">是否位于<head>内首个非空非注释标签且文件实际为UTF-8无BOM。
浏览器打开 HTML 页面显示中文乱码，基本就是编码声明、文件实际编码、HTTP 响应头三者中至少一个没对上。其他花哨原因占比极低，先盯死这三点。
怎么快速确认是不是 <meta charset="UTF-8"> 失效了
这个标签不是写了就管用，它只在前 1024 字节内被扫描，且前面不能有任何干扰。
- 打开开发者工具 → Network → 刷新页面 → 找到主 HTML 请求 → 点开 → Headers → 查看 Response Headers 里的
Content-Type。如果值是text/html; charset=gbk或压根没charset，那<meta>已被无视，直接跳到下个副标题 - 如果
Content-Type正确（含charset=utf-8），再检查 HTML 源码：<meta charset="UTF-8">必须是<head>内第一个非空、非注释的标签；前面不能有空格、换行、<!-- -->、BOM 字节 - 常见写错：
<meta charset="utf8">（缺横线）、<meta charset="UTF8">（大小写不标准）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML5 不推荐，且优先级低于charset属性）
VS Code 里显示“GBK”但你写了 <meta charset="UTF-8"> 怎么办
编辑器显示的编码，就是文件实际保存的编码。显示“GBK”，说明文件根本不是 UTF-8，<meta> 就是空中楼阁。
- 右下角点击当前编码（如“GBK”或“UTF-8 with BOM”）→ 选
Save with Encoding→ 严格选UTF-8（注意：不是UTF-8 with BOM） - 保存后，右下角应显示“UTF-8”，且无“with BOM”字样；若仍显示“UTF-8 with BOM”，说明 VS Code 在 Windows 下默认加了 BOM，必须手动选纯 UTF-8
- 验证是否真清除了 BOM：Linux/macOS 运行
head -c 4 index.html | xxd，输出不应含ef bb bf；Windows PowerShell 运行Get-Content index.html -Encoding Byte | Select -First 3，前三字节不应是239, 187, 191
HTTP 响应头 Content-Type 覆盖了 <meta> 怎么查和改
服务器发的 HTTP 头比 HTML 里的 <meta> 权重更高。本地双击打开（file:// 协议）时它不存在，但只要走 HTTP（哪怕 python -m http.server），它就起决定作用。
立即学习“前端免费学习笔记（深入）”；
- F12 → Network → 刷新 → 主 HTML 请求 → Response Headers → 看
Content-Type值。常见错误值：text/html（缺 charset）、text/html; charset=iso-8859-1（Python 默认）、text/html; charset=gbk（Nginx 旧配置） - Nginx 配置需加
charset utf-8;（在http、server或location块内），不是add_header Content-Type（那是覆盖，可能出错） - Node.js/Express：必须在
res.send()前调用res.set("Content-Type", "text/html; charset=utf-8")；res.sendFile()默认不带 charset，得手动设 - PHP：必须在任何输出（包括空格、BOM）之前调用
header("Content-Type: text/html; charset=utf-8")；BOM 会导致header()失败，报 “headers already sent”
<script> 和 <link> 引入的 JS/CSS 也乱码怎么办
HTML 本身没问题，但外部资源加载时用了错误编码，一样会触发乱码——尤其是中文注释、字符串或字体名。
- 单独访问 JS/CSS 文件 URL（如
http://localhost/app.js），看浏览器地址栏是否显示乱码；如果是，说明该文件本身保存编码不对，按第二副标题方法处理 - 检查引入标签是否显式声明编码：
<script src="app.js" charset="UTF-8"></script>（虽已过时，但某些老环境仍依赖） - 更稳妥的是确保 Web 服务器对
.js和.css响应头也设了charset=utf-8；Nginx 可配location ~ \.(js|css)$ { add_header Content-Type "text/javascript; charset=utf-8"; } - 注意：现代浏览器通常按 HTML 的 charset 推断外部资源编码，但若 JS/CSS 文件开头有 BOM 或服务器返回了冲突的
Content-Type，仍会出问题
真正麻烦的从来不是单点问题，而是三者嵌套失效：文件存成 GBK，<meta> 写错位置，Nginx 又返回 charset=iso-8859-1。排查时务必逐层剥离，从 Network 面板的 Content-Type 入手，它是最权威的“当前生效编码”信号。
