必须且仅写一次，但常因http响应头content-type: charset=gbk覆盖、本地file://协议下文件实际为gbk编码、bom导致解析失败或外部资源编码不一致而失效；验证应以network面板response headers中charset=utf-8为准，而非编辑器显示。
meta charset="UTF-8" 必须写，且仅写一次；但光靠它远远不够——乱码往往发生在它“被忽略”或“被覆盖”的环节。
为什么 meta charset="UTF-8" 有时不起作用
浏览器只在无法从 HTTP 响应头获取编码时，才 fallback 到 meta。一旦服务器返回了 Content-Type: text/html; charset=GBK，哪怕 meta 写得再标准，也会按 GBK 解析，直接崩出乱码。
- 本地双击打开 HTML 文件（
file://协议）时，meta是唯一依据，此时若文件实际是 GBK 编码，meta就会强制错解 - 开发服务器（如 Vite、Webpack Dev Server）默认发 UTF-8 响应头，但若你手动调用
res.sendFile()且没设 header，Node.js 默认不带 charset - GitHub Pages、Vercel 等平台虽默认 UTF-8，但若上传含 BOM 的 UTF-8 文件，部分旧工具会误判为“带签名的非标准 UTF-8”，触发兼容模式
如何验证当前页面真实生效的编码
别信编辑器右下角显示的“UTF-8”——那是文件保存格式，不是浏览器解析所用编码。打开浏览器开发者工具：
- 切到 Network 面板，刷新页面
- 点击左侧列表中的 HTML 请求（通常是第一个
document类型） - 在右侧 Response Headers 中找
Content-Type字段值，确认是否含charset=utf-8 - 再点 Preview 或 Response 标签页，直接看原始字节渲染效果：若开头出现 或 “锟斤拷”，说明解析已失败
VS Code 保存 HTML 文件时的关键操作
VS Code 默认保存为 UTF-8，但“UTF-8 with BOM”和“UTF-8”是两回事。BOM（EF BB BF）在 HTML 中属于非法前导字节，会导致：
前多出不可见字符，某些老版本 IE 直接拒识文档类型- PHP/Node.js 拼接输出时，BOM 被当作响应体内容提前发出，导致 header 设置失败
- Webpack/Vite 构建时可能报
Invalid character（尤其在 JSON 或 JS import 路径中）
正确做法：保存时点右下角编码 → Save with Encoding → 选 UTF-8（明确不含 “with BOM” 字样）；可用命令行验证：xxd -l 4 yourfile.html，输出不含 ef bb bf 才算干净。
lang 属性不是编码设置，但影响中文呈现细节
lang="zh-CN" 不解决乱码，但它决定浏览器如何处理中文排版：
- 影响标点挤压（如中文顿号、引号间距）、断行策略（是否允许在中文词间断）、字体回退顺序
- 必须写在
根标签上，而非仅内；子元素可覆盖，如<p lang="en">Hello</p> - 若服务端动态生成页面，
lang值应随用户语言偏好同步，不能硬编码死
真正容易被忽略的是：**编码一致性必须贯穿整个链路——文件存盘、HTTP 响应、外部 CSS/JS 文件、AJAX 返回数据，四者缺一不可**。任一环节掉链，meta charset 就成了摆设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
