html字符编码必须用显式声明且置于最开头，否则浏览器按默认编码解析导致乱码；文件保存编码须为utf-8（无bom）；服务端响应头与html声明应一致，本地打开时仅生效。
HTML 页面的字符编码必须显式声明，否则浏览器可能按错误编码解析内容，导致中文乱码、表单提交异常、JS 字符串截断等问题。最可靠的方式是用 <meta charset> 声明 UTF-8，且必须放在 最前面（在任何其他标签之前）。
为什么 <meta charset="UTF-8"> 必须放
浏览器从上到下解析 HTML，一旦遇到非 ASCII 字符（比如中文），而此时还没读到 charset 声明，就会按默认编码（如 ISO-8859-1 或系统本地编码）尝试解码——这个过程不可逆，后续即使再出现 <meta charset> 也无法修正已错读的内容。
常见现象：<title>你好</title> 显示为 “ä½ å¥½”，console.log("测试") 输出乱码字符串。
- 它必须是
中第一个标签（紧接开始标签之后） - 不能写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这种旧写法依赖 HTTP 头优先级，且部分浏览器（如旧版 Safari）不保证识别 - 服务器返回的 HTTP
Content-Type头（如text/html; charset=utf-8）优先级高于<meta>，但不能替代它：本地打开 HTML 文件时无 HTTP 头，全靠<meta charset>
文件保存编码必须和 charset 声明一致
声明 UTF-8 却用 GBK 编码保存文件，浏览器照样会乱码——因为字节流本身就不对。
- 用 VS Code / Sublime / WebStorm 等编辑器时，右下角检查当前编码显示，点击切换为
UTF-8（不含 BOM） - 避免选
UTF-8 with BOM：BOM（EF BB BF）会在页面开头插入不可见字节，可能导致 CSS/JS 解析失败或空白行 - Node.js 服务端用
fs.readFileSync(path, 'utf8')读取 HTML 时，也要确保文件确实是 UTF-8 编码，否则抛ERR_INVALID_CHAR
服务端响应头与 HTML 声明不一致时以谁为准
HTTP Content-Type 头中的 charset 优先级高于 <meta charset>，但二者冲突会导致不可预测行为（尤其在移动端 WebView 或低版本 Android 浏览器中）。
- PHP 中不要用
header('Content-Type: text/html; charset=gbk');同时又写<meta charset="UTF-8"> - Nginx 配置里慎用
charset gbk;，它会强制加 HTTP 头，覆盖 HTML 内声明 - 最佳实践：服务端统一设
charset=utf-8，HTML 里也写<meta charset="UTF-8">，双保险
最容易被忽略的是：本地开发时直接双击打开 HTML 文件，此时完全不走 HTTP 协议，<meta charset> 是唯一生效的编码声明方式——哪怕你服务器配置得再完美，本地预览出错，就是这里没写对或文件编码不对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
