HTML charset声明必须置于内第一个有效标签位置，否则浏览器可能因提前解析非ASCII字符而触发编码重载导致乱码；推荐使用而非http-equiv写法，且服务端Header优先级高于HTML meta。
HTML charset必须写在最前面
浏览器解析HTML时，遇到第一个非ASCII字符就可能触发编码重载，如果charset声明太靠后，前面的中文、符号或特殊标点会乱码——哪怕你写了UTF-8也白搭。
常见错误现象：、问号方块、部分文字显示为乱码，但刷新后又正常（说明浏览器中途切换了编码）。
- 必须放在
内，且是里**第一个**有实际作用的标签（注释和空格不算） - 不能写在
<title></title>后面、<meta name="viewport">后面，更不能塞进 - 推荐写法：
<meta charset="UTF-8">，不要用http-equiv="Content-Type"那种老式写法
为什么不用
这种写法本质是模拟HTTP头，但现代浏览器对它的解析优先级低、行为不一致，尤其在无网络环境（如本地file://协议打开）下大概率失效。
使用场景：只在维护十多年前的老系统、且无法改<meta charset>时才考虑它。
立即学习“前端免费学习笔记（深入）”；
-
<meta charset="UTF-8">是HTML5标准语法，浏览器支持度100%，解析快、位置敏感但明确 -
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">容易被忽略，Safari 14之前在某些条件下会跳过 - 二者参数差异：前者只认
charset值；后者要求完整MIME类型字符串，拼错一个字符（比如多空格、少分号）就失效
服务端Header和HTML meta冲突时谁赢
HTTP响应头里的Content-Type（含charset）优先级永远高于HTML里的<meta charset>。这不是bug，是规范设计。
性能影响：如果服务端返回了charset=GBK，而你HTML里写UTF-8，浏览器会先按GBK解码，发现乱码后再重载——页面闪动、JS执行延迟、CSS加载中断都可能发生。
- 查服务端编码：用浏览器开发者工具的Network面板看Response Headers里的
Content-Type - PHP用户注意：
header("Content-Type: text/html; charset=UTF-8");必须在任何输出前调用 - Node.js/Express用户：确保
res.set("Content-Type", "text/html; charset=utf-8")早于res.send()
不写charset时浏览器怎么猜
没声明charset时，浏览器会按默认编码（通常是系统locale相关）尝试解码，比如Windows简体中文系统默认用GBK，Mac默认用UTF-8——同一份HTML在不同机器上显示结果可能完全不同。
兼容性影响：IE6–8会直接按系统编码硬解，Chrome/Firefox虽有BOM检测和统计分析，但遇到无BOM的UTF-8文件仍可能误判为ISO-8859-1。
- 即使所有文字都是ASCII（a-z, 0-9），也不代表安全——CSS里的
content: "→";、JS里的const str = "✅";都可能触发解码失败 - 生成HTML的模板引擎（如Jinja2、EJS）默认不自动加
charset，要手动补 - 静态站点生成器（如Hugo、VuePress）一般自带，但主题模板若覆盖了
，可能意外删掉它
file://协议下没有HTTP头，全靠<meta charset>撑着，这时候位置不对或漏写，乱码问题会来得特别突然、特别安静。 
