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