不写 会导致中文乱码、表单提交乱码、JS字符串处理异常、CSS中文解析失败；该标签须置于最前，且HTML文件本身必须为UTF-8编码（无BOM），否则无效。
不写
浏览器在没有明确编码声明时，会按自己的启发式规则猜测页面编码，常见后果包括：
中文显示为乱码（如“æ°é»”）、表单提交后后端收到乱码、JavaScript 字符串处理异常（比如 str.length 计算错误）、CSS 中的中文注释或字体名解析失败。
这个标签必须是 中第一个能影响字符解析的元素，否则浏览器可能已按错误编码读取了后续内容。尤其不能放在 后面。
页面标题
如果顺序颠倒，比如把 也来不及修正。
HTML 文件本身也得是 UTF-8 编码，光写 meta 没用
仅在 HTML 中写 不足以保证正确显示——源文件保存时必须用 UTF-8 编码（不含 BOM）。常见陷阱有：
立即学习“前端免费学习笔记（深入）”；
- 用记事本另存为 UTF-8 时默认带 BOM，某些服务器或工具会把 BOM 当作响应头前的非法字符，导致
Cannot modify header information类错误 - VS Code 默认保存为 UTF-8，但若项目中混入 GBK 编码的旧文件，
无法“修复”它，只会让乱码更稳定地呈现 - HTTP 响应头
Content-Type: text/html; charset=gbk会覆盖，此时优先级：HTTP header >> 浏览器自动探测
服务端配置比前端 meta 更可靠
真正一劳永逸的方式是让 Web 服务器（如 Nginx、Apache）或后端框架（如 Express、Django）统一返回 Content-Type: text/html; charset=utf-8。这样即使漏写或错放 ，页面仍大概率正常渲染。
但注意：如果服务端没配，又没写 ，且 HTML 里出现中文，就等于把解码权完全交给浏览器猜——而不同浏览器、不同语言环境下的猜测逻辑并不一致。
实际项目里， 是底线，不是可选项；它不解决所有编码问题，但不写，几乎一定会出问题。
