应仅在维护遗留GBK编码系统时使用<meta charset="GBK">，且必须置于<head>最开头、文件实际编码与之严格一致；HTTP响应头优先级更高，本地file://协议下完全依赖meta与文件编码匹配。
HTML中设置charset="GBK"的适用场景
只有当页面内容确实以 GBK 编码保存时，才应使用 charset="GBK"。比如维护一个十几年前遗留的政府内网系统，原始 HTML 文件用 Windows 记事本保存为 GBK，且后端模板、数据库连接、HTTP 响应头全部未改造——此时强行改成 UTF-8 可能引发更严重的解码错位或乱码扩散。但绝大多数新项目、跨平台部署、含 emoji 或多语言内容的页面，都不该选 GBK。
<meta charset="GBK">必须放在<head>最开头
浏览器只扫描文件开头 1024 字节寻找 meta charset，一旦前面有 BOM、注释、空行、<script> 或 <title>，就可能失效，fallback 到系统默认编码（Windows 下常为 GBK 自身，看似“正常”，实则掩盖问题）。
- ✅ 正确写法：
<head><meta charset="GBK"><title>... - ❌ 错误写法：
<head><!-- 注释 --><meta charset="GBK">（注释占位导致扫描失败） - ❌ 错误写法：
<head><script>...</script><meta charset="GBK">（JS 阻断扫描）
文件实际编码必须与meta charset值严格一致
如果 HTML 文件用 VS Code 以 UTF-8 保存，但写了 <meta charset="GBK">，浏览器就会用 GBK 解 UTF-8 字节流，中文变成类似 ۡ 的乱码；反之，文件是 GBK 编码却写 charset="UTF-8"，也会出同样问题。
- 验证文件真实编码：Linux/macOS 运行
file -i index.html；Windows PowerShell 运行Get-Content index.html -Encoding Byte | Select -First 3查看是否为239, 187, 191（UTF-8 BOM）或其他字节序列 - VS Code 中右下角显示编码名，点击可切换 “Save with Encoding” → 选
GBK（注意：VS Code 默认不内置 GBK 支持，需装扩展如 “Chinese (GBK) Language Support”） - Notepad++ 中：编码 → 转为 ANSI（即 GBK），再保存
HTTP 响应头优先级高于meta charset
当服务器返回 Content-Type: text/html; charset=UTF-8 时，即使 HTML 里写了 <meta charset="GBK">，Chrome/Firefox 也会按响应头执行，无视 meta。这在调试时容易误判。
立即学习“前端免费学习笔记（深入）”；
- 查响应头：DevTools → Network → 点 HTML 请求 → Headers → Response Headers →
Content-Type - Apache 配置：
AddDefaultCharset GBK或Header set Content-Type "text/html; charset=GBK" - Nginx 配置：
charset GBK;（注意不是add_header） - Node.js/Express：
res.set('Content-Type', 'text/html; charset=GBK')
本地双击打开 file:// 页面时，HTTP 响应头不存在，此时完全依赖 meta charset 和文件实际编码，最容易暴露不一致问题。
