必须将<meta charset="UTF-8">置于<head>最前面，否则浏览器可能按错误编码解析中文等非ASCII字符，导致乱码、表单异常、JS截断等问题；UTF-8大小写不敏感但推荐小写；HTTP响应头优先级高于meta声明；本地file://协议下完全依赖该meta声明。
HTML 页面必须显式声明 charset，否则浏览器可能按错误编码解析文本，导致中文乱码、表单提交异常、JS 字符串截断等问题——这不是“可能出错”，而是“大概率出错”，尤其在无服务器响应头干预的静态文件场景下。
为什么 <meta charset> 必须放在 <head> 最前面
浏览器解析 HTML 是流式进行的。一旦遇到非 ASCII 字符（比如中文），而此时还没读到 <meta charset="UTF-8">，就会按默认编码（如 ISO-8859-1 或系统本地编码）解码已读入的字节，后续即使再声明也无力回天。
- 错误写法：
<head><title>我的页面</title><meta charset="UTF-8"></head>→<title>中的中文可能已被错误解码 - 正确写法：
<head><meta charset="UTF-8"><title>我的页面</title></head>→ 确保首个标签即编码声明 - 更稳妥：把
<meta charset>放在<head>内第 1 行，前面不加注释、空格或 BOM
charset 值该用 UTF-8 还是 utf-8？大小写敏感吗？
不敏感，但推荐统一小写 UTF-8。HTML5 规范明确说明该值不区分大小写，浏览器均支持 utf-8、UTF-8、Utf-8。但注意：
- 服务器响应头中的
Content-Type: text/html; charset=utf-8—— 这里charset参数值同样不区分大小写，但惯例全小写 - 若 HTML 文件本身含 BOM（如 UTF-8 with BOM），某些旧版 IE 可能忽略
<meta>声明，直接按 BOM 推断 → 应保存为 “UTF-8 无 BOM” 格式 - 不要写
UTF8（缺短横线）或Unicode（不是有效值），会退化为默认编码
当 <meta charset> 和 HTTP 响应头冲突时，谁生效？
HTTP 响应头优先级高于 <meta>。例如服务器返回 Content-Type: text/html; charset=GBK，即使 HTML 里写了 <meta charset="UTF-8">，Chrome/Firefox 也会按 GBK 解析。
立即学习“前端免费学习笔记（深入）”；
- 调试方法：打开 DevTools → Network → 点开 HTML 请求 → 查看 Response Headers 中的
Content-Type - 本地双击打开的
file://协议页面，无响应头，完全依赖<meta charset> - Node.js/Python 等后端需显式设置响应头，例如 Express 中：
res.set('Content-Type', 'text/html; charset=UTF-8')
不用 <meta charset> 的替代方案有哪些？靠谱吗？
有，但都不如它直接可靠：
-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— HTML4 写法，兼容性好，但冗长且易被误写成content-type（少横线）而失效 - 依赖服务器配置（如 Apache 的
AddDefaultCharset UTF-8）—— 有效，但无法覆盖单个文件的特殊需求，且静态托管平台（如 GitHub Pages、Vercel）未必开放配置 - 完全不设，靠浏览器自动探测 —— 现代浏览器基本放弃 auto-detect，尤其对中文内容极易判错
真正省事又通用的做法，就是老老实实写一行 <meta charset="UTF-8">，并确保它在 <head> 最顶上。别信“浏览器能猜对”，它猜错的成本远高于你多敲几个字母。
