meta charset="UTF-8" 是唯一推荐方案，HTML5规范仅认可该写法，需置于<head>最前、文件保存为UTF-8无BOM、HTTP响应头charset一致，三者缺一不可。
meta charset="UTF-8" 是唯一推荐，不存在“更省空间”的替代方案
直接说结论：meta charset="UTF-8" 就是当前 HTML 中最合理、最兼容、实际占用字节数最少的字符编码声明方式。所谓“省空间”如果指 HTML 文件体积，那它本身只占 21 字节（<meta charset="UTF-8">），比任何其他合法写法都短；如果指传输或内存开销，UTF-8 本身就是变长编码——ASCII 字符仍为 1 字节，中文通常 3 字节，远优于 UTF-16 或 GBK 在混合内容下的平均膨胀率。
为什么 utf8、UTF_8、unicode 都不合法且可能失效
HTML5 规范只接受 UTF-8（全大写 U/T/F，数字 8，中间短横）作为合法值。其他写法会导致部分环境 fallback 到系统默认编码：
-
utf8：Chrome 可能容忍，但某些 WebView（如旧版 Android System WebView）或 html-webpack-plugin 构建流程会直接忽略，退到 ISO-8859-1 -
UTF_8或utf-8（小写 u）：不符合 IANA 注册标准，Nginx + FastCGI 场景下可能被截断或误解析 -
unicode：完全无效，浏览器无法识别，必然 fallback
meta charset 必须出现在 <head> 最开头，否则白写
浏览器只扫描 HTML 前 1024 字节来查找 meta charset，且仅识别 ASCII 范围内的字符。这意味着：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 不能放在
<title>后面——哪怕只差一个换行，就可能错过 - 前面不能有注释
<!-- -->、空格、BOM（EF BB BF）或<script> - VS Code 默认保存不带 BOM，但 Notepad++ 默认带；若文件以 BOM 开头，
<!DOCTYPE html>前多了 3 字节，meta就可能被跳过
真正影响“空间”和稳定性的其实是文件保存格式与 HTTP 头
单看标签没用，三者必须一致：
立即学习“前端免费学习笔记（深入）”；
- 文件本身要存为 UTF-8（无 BOM 更稳妥，避免开头多出 3 字节干扰扫描）
- Web 服务器要发
Content-Type: text/html; charset=UTF-8（Nginx 写charset utf-8;，Apache 用AddDefaultCharset UTF-8） - 如果用了构建工具（如 Vite、Webpack），确认插件没把
index.html重编码成 GBK 或 ANSI
任一环节错位，比如文件是 UTF-8 但 HTTP 头声明 charset=GBK，浏览器就直接按 GBK 解码——此时 meta 标签里的中文会变成乱码字节，整个页面崩掉。
