结论：99%场景无需适配GB2312，误设会导致乱码和错误；仅当同时满足老旧系统四条件（XP/IE6–8、ASP+Access或Java设GB2312响应、HTTP头含charset=GB2312、文件实际为ANSI编码）时才需处理，且必须同步修改文件编码与后端配置。
直接说结论：不要主动“设置 HTML 去适配老旧系统编码”，而是先确认你是否真的在和老旧系统打交道——99% 的场景下，所谓“适配 GB2312”其实是误判，强行改只会让现代浏览器乱码、构建工具报错、接口返回异常。
怎么判断你的环境真需要 GB2312
老旧系统不是指“页面看起来旧”，而是满足以下全部条件：
- 运行在 Windows XP / IE6–8 或某台离线内网终端上
- 后端是 ASP + Access 数据库，或 Java Web 项目里还写着
response.setCharacterEncoding("GB2312") - HTTP 响应头明确包含
Content-Type: text/html; charset=GB2312 - 你手里的 .html 文件用记事本打开，右下角显示“ANSI”且保存时没有问号或方块
只要漏掉其中一环，单改 <meta charset="GB2312"> 就等于告诉浏览器“请用错误的钥匙开锁”。Chrome v100+ 之后会直接忽略该声明，强制按 UTF-8 解析。
改文件实际编码比改 meta 更关键
<meta> 只是提示，磁盘上字节怎么存才是根本。编辑器决定写入什么编码，不是 HTML 标签。
立即学习“前端免费学习笔记（深入）”；
- VS Code：右下角点当前编码（如
UTF-8）→Save with Encoding→ 选GB2312（注意不是GBK或GB18030） - Notepad++：菜单栏
编码→转为ANSI→ 再另存为，编码选ANSI（Windows 简体中文系统下 ANSI = GB2312） - Sublime Text：
File→Save with Encoding→Chinese (GB2312)
改完立刻用记事本打开检查：有没有 ?、方块、或者“镕”“晞”这类字变成空格——GB2312 只支持 6763 个汉字，缺字即静默丢失，不可逆。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
HTTP 响应头和后端必须对齐
前端改了编码，后端没跟上，照样全链路乱码。重点核对三处：
- 后端代码中是否显式设置了响应编码，例如 Java 的
response.setCharacterEncoding("GB2312")，PHP 的header('Content-Type: text/html; charset=GB2312') - 数据库连接 URL 是否带
useUnicode=true&characterEncoding=gb2312（MySQL）或对应参数（SQL Server/Oracle） - Nginx/Apache 是否在配置里加了
charset GB2312;，且未被更高级别的charset utf-8;覆盖
少一个环节，就可能表现为表单提交后中文变问号、AJAX 返回空字符串、或者控制台报 Failed to load resource: net::ERR_CONTENT_DECODING_FAILED。
现代框架里硬切 GB2312 几乎必然失败
Vite/Webpack 默认按 UTF-8 处理所有资源；Vue SFC 编译器读取 .vue 文件时若检测到非 UTF-8 字节，会直接抛 ParseError；React 的 JSX 解析器也不接受 GB2312 编码的源码文件。
如果你正在用这些工具链，却还在想“怎么让 Vite 输出 GB2312 页面”，说明你真正该做的不是改构建配置，而是确认：这个页面是否真的需要部署到那个老旧环境？还是只是测试时模拟？后者完全可以用本地 Python HTTP 服务器起一个 GB2312 响应头 + 手动编码的 HTML 文件来验证，不必污染整个工程。
最常被忽略的一点：微信公众号、钉钉、企业微信内嵌 WebView 已彻底弃用 GB2312，即使你把所有环节都设对了，它们也会在加载时强制转成 UTF-8 —— 这不是 bug，是平台策略。
