必须置于最开头、之前，因浏览器流式解析时若未及时读取该标签，将默认用ISO-8859-1解码，导致中文、emoji及特殊符号全部乱码；其值须严格为UTF-8（大小写、连字符、无空格），且文件编码、HTTP响应头charset、meta声明三者必须完全一致方可生效。
必须写 ，且必须放在 开头、
为什么
浏览器解析 HTML 是从上到下流式进行的。一旦遇到 <script></script>，就会立即尝试解码其中的文本。如果此时还没读到 ，它就只能用默认编码（通常是 ISO-8859-1 或 Windows-1252）去解，导致：
-
你好 -
console.log("测试")在 DevTools 中报Uncaught SyntaxError: Invalid or unexpected token - 表单提交中文字段变成乱码或空值
- emoji 渲染失败，显示为方块或问号
这不是“偶尔出错”，而是确定性行为——只要位置靠后，Chrome/Firefox/Safari/Android WebView 都会这样。
charset 的值写 UTF-8 还是 utf-8？大小写和空格影响吗？
HTML5 规范明确要求值为 UTF-8（全大写 U、T、F，中间连字符，末尾无空格）。虽然多数浏览器也接受 utf-8、UTF8、utf8，但以下场景会出问题：
- 某些嵌入式 WebView（如旧版 Android 系统、IoT 设备）只识别严格
UTF-8 - W3C 验证器报错：
Bad value utf-8 for attribute charset on element meta. - CI 流水线中自动化检查（如 html-validate）直接拒绝非标准写法
-
（末尾空格）在部分 Node.js 模板引擎中会被截断，变成无效值
所以只用这一种：，不加空格、不换行、不缩进。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
写了
meta 标签只是前端声明，实际生效依赖三个环节完全一致：
-
文件本身必须是 UTF-8 编码（无 BOM）：用 VS Code 查右下角编码标识，点开选 “Save with Encoding → UTF-8”；别选 “UTF-8 with BOM”，BOM（
EF BB BF）会干扰某些服务器或 JS 解析 -
HTTP 响应头
Content-Type必须含charset=UTF-8：打开 Chrome DevTools → Network → 点 HTML 请求 → Headers → Response Headers，确认有Content-Type: text/html; charset=UTF-8；若看到charset=GBK或没这个字段，需改服务器配置（Nginx 加charset utf-8;，Express 用res.set('Content-Type', 'text/html; charset=UTF-8')） -
本地双击打开（
file://协议）时，完全依赖：此时没有 HTTP 头，是唯一依据，务必确保它在最前，且文件保存为 UTF-8
三者只要有一处不匹配，比如文件存为 GBK 却写 UTF-8，或服务器返回 charset=GBK 却写 UTF-8，浏览器就会忽略 meta 标签，按响应头或文件二进制内容强行猜测编码，结果就是不可控乱码。
能不能用
可以，但不推荐：
- HTML4 写法，HTML5 已被
charset属性替代，冗长且易拼错（比如漏写http-equiv、content 值少引号） - 部分老 IE 对
http-equiv解析不稳定，尤其当它不是第一个 meta 时 - 如果同时存在
和，后者会被忽略——现代浏览器只认前者 - Webpack/Vite 等构建工具生成的 HTML 模板，若模板里混用两种写法，可能被插件误删或覆盖
一句话：只用 ，删掉所有 http-equiv 版本，避免干扰。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
