不写 charset 不一定乱码，因浏览器按响应头、meta 标签（需在前1024字节且无bom）、启发式检测三级推断编码；但任一环节错配（如服务端声明gbk、meta位置超限、utf-8带bom）均会导致中文乱码。
charset 不写，确实可能乱码，但不是“一定”乱码——取决于服务器响应头、HTML 文档位置、浏览器解析顺序和实际字节流内容。
为什么没写 charset 有时也正常？
现代浏览器（Chrome、Edge、Firefox）在解析 HTML 时会按固定优先级尝试推断编码：
- HTTP 响应头中的
Content-Type: text/html; charset=utf-8优先级最高 - HTML 中的
<meta charset="utf-8">（必须位于前 1024 字节内，且不能含非 ASCII 字符）次之 - 若两者都缺失，浏览器会启用启发式检测（如 IE 的 Auto-Detect、Chromium 的 Compact Language Detector），对中文页面常误判为
GBK或ISO-8859-1
所以：静态文件托管在 GitHub Pages、Vercel 等平台时，若服务端没配 charset 响应头，又没写 <meta charset>，打开本地双击 HTML 文件或通过 file:// 协议访问，大概率出现中文乱码（显示为 或方块）。
<meta charset> 放错位置就失效
这个标签必须满足两个硬性条件才能被识别：
- 必须出现在
内，且是中前几个标签之一 - 整个标签（包括开始、结束、引号、等号）必须落在文档开头的 1024 字节范围内
- 不能写成
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">—— 这种旧写法在 HTML5 中已不推荐，部分浏览器（尤其是 Safari iOS）可能忽略
常见翻车现场：<meta> 前面不小心加了注释、空行、BOM 头，或者被构建工具（如 Webpack 的 html-webpack-plugin）插在了 <title></title> 后面——此时浏览器已按默认编码（如 Windows-1252）解析了一段内容，再改 charset 也晚了。
服务端没设 charset 响应头，前端补 meta 也不保险
当后端返回的 HTTP 响应头明确声明了 Content-Type: text/html; charset=gbk，哪怕你在 HTML 里写了 <meta charset="utf-8">，浏览器仍以响应头为准（W3C 规范强制要求）。这时乱码不是因为没写，而是前后不一致。
- Node.js + Express：用
res.set('Content-Type', 'text/html; charset=utf-8') - Nginx：在
location块中加add_header Content-Type "text/html; charset=utf-8";（注意：这会覆盖原有值，慎用） - Apache：在
.htaccess中写AddDefaultCharset utf-8
更稳妥的做法是服务端统一输出 UTF-8 响应头 + HTML 内置 <meta charset="utf-8">，双保险。别依赖浏览器猜。
UTF-8 BOM 是个隐藏陷阱
如果 HTML 文件本身以 UTF-8 with BOM（即开头三个字节 EF BB BF）保存，即使写了 <meta charset="utf-8">，某些旧版 IE 和部分嵌入式 WebView 会把 BOM 当作不可见字符解析进 DOM，导致 JS 报错或 CSS 渲染异常；而 Chrome 虽能跳过 BOM，但可能因此错过前 1024 字节内有效的 <meta> 标签位置判断。
- 用 VS Code 打开文件 → 右下角查看编码 → 点击切换 → 选 “Save with Encoding” → “UTF-8”（不含 BOM）
- 用命令行检查：
xxd index.html | head -1，若输出含ef bb bf就是带 BOM - Git 用户注意：
git config --global core.autocrlf true在 Windows 下可能意外引入 BOM，建议设为false并统一换行符
真正容易被忽略的，不是该不该写 charset，而是它生效的前提太苛刻：服务端头、文件编码、HTML 位置、BOM 状态，四者只要一个没对齐，乱码就来了——而且问题只在特定环境复现，本地好好的，上线就崩。
