网页乱码主因是编码声明失效：<meta charset="UTF-8">必须置于<head>最前、任何内容（含<title>、注释、BOM）之前；若位置错误、文件编码不匹配或服务器响应头Content-Type优先级更高，浏览器将回退至系统默认编码（如Windows的GBK）解析，导致中文显示为方块或问号。
为什么网页显示乱码，meta charset 放错位置就失效
浏览器默认用系统编码（比如 Windows 的 GBK）解析 HTML，如果文件实际是 UTF-8 编码但没声明，中文就会变方块或问号。关键不是“加不加”，而是 <meta charset="UTF-8"> 必须在 <head> 开头、且**必须出现在任何可能触发解析的内容之前**——比如不能放在 <title> 后面，更不能塞进 <body> 里。
- 错误写法：
<head><title>页面</title><meta charset="UTF-8"></head>（<title>已触发部分解析，charset 晚了） - 正确位置：
<head><meta charset="UTF-8"><title>页面</title></head> - 如果用了
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，它和charset属性效果等价，但更冗长，优先用简写
VS Code 保存文件编码和 meta charset 不一致时照样乱码
编辑器保存的编码格式和 HTML 声明必须严格匹配。常见坑是：文件明明存成 UTF-8，但 VS Code 底部状态栏显示的是 UTF-8 with BOM —— 这个 BOM（字节序标记）会被某些旧浏览器误读，导致页面开头多出空白或乱码。
- VS Code 中点击右下角编码名称 → 选
Save with Encoding→ 选UTF-8（不含 BOM） - Sublime Text 默认存为无 BOM UTF-8，但需确认右下角显示的是
UTF-8而非UTF-8-BOM - 用命令行检查：
file -i your-page.html（Linux/macOS），看输出中charset=utf-8是否出现，且无bom字样
服务器响应头 Content-Type 比 meta charset 优先级更高
当 Web 服务器（如 Nginx、Apache）返回的 HTTP 响应头里有 Content-Type: text/html; charset=GBK，浏览器会直接忽略 HTML 内的 meta charset，强行按 GBK 解析——结果就是无论你怎么改 HTML，页面还是乱码。
- 用浏览器开发者工具 → Network → 刷新页面 → 点开 HTML 请求 → 查看 Response Headers 中的
Content-Type - Nginx 配置中检查是否有
charset gb2312;或类似指令，应删掉或改为charset utf-8; - 本地用
python -m http.server启的服务默认不发 charset，此时才真正依赖meta charset
HTML5 中 meta charset 是唯一推荐写法，别用老式 http-equiv
HTML5 明确规定 <meta charset="UTF-8"> 是标准且最简方式。老式写法 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 虽然还能用，但多写了 20 多个字符，语义也不如前者清晰，还容易漏掉引号或拼错 http-equiv。
立即学习“前端免费学习笔记（深入）”；
- 只写一次，且只放一个
<meta charset>—— 多个不会叠加，浏览器只认第一个 - 值必须是真实支持的编码名，
UTF-8全大写或全小写都行，但utf8（无横线）在某些旧环境可能不识别，坚持用UTF-8 - 如果页面内容来自后端模板（如 PHP、Jinja），确保模板输出的
<meta charset>在<head>最前面，而不是被动态插入到中间
meta charset 声明、服务器响应头 Content-Type。少对一环，乱码就回来。 
