必须设且文件存为utf-8无bom格式，缺一不可；因meta仅告知浏览器解码方式，不保证文件真实编码，常见断点包括编辑器误存为ansi/gbk/utf-8 with bom、服务器响应头覆盖meta、富文本插入隐藏控制字符等。
必须设 <meta charset="UTF-8">，且文件本身存为 UTF-8 无 BOM 格式——缺一不可，否则任何实体或 Unicode 直输都可能崩。
为什么加了 <meta charset="UTF-8"> 还乱码
因为 meta 只是“告诉浏览器怎么解码”，不等于“文件真是 UTF-8”。常见断点：
- 编辑器保存时选了 ANSI、GBK 或 UTF-8 with BOM → 实际字节流不是标准 UTF-8，浏览器强行按 UTF-8 解就出
- 服务器响应头
Content-Type返回了text/html; charset=gbk→ 覆盖 HTML 里的 meta，浏览器优先信响应头 - 富文本编辑器（如 CKEditor、TinyMCE）导出内容时自带隐藏控制字符（比如零宽空格
），肉眼不可见但破坏编码边界
<meta charset="UTF-8"> 必须放在
它得在解析器读到第一个非 ASCII 字符前就被识别，否则前面的中文/书名号已按默认编码（通常是系统 locale）错解了。实操要点：
- 确保它是
中第一个标签（连注释都不能放它前面） - 不要写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这是旧写法，兼容性差，某些老 WebView 不认 - 用开发者工具的 Network 面板检查响应头，确认
Content-Type确实含charset=UTF-8；若不一致，需改服务器配置（如 Nginx 加charset utf-8;）
Unicode 直输比 HTML 实体更稳，但有前提
像 ©、《、✓ 这类符号，直接键盘输入或复制粘贴进 HTML 比写 ©、【 更可靠——前提是编码环境干净。注意：
- VS Code 默认保存为 UTF-8 无 BOM，但右下角状态栏要手动点开确认，有时会悄悄切回 GBK
- 别在 Word 里写完再粘贴：Word 自动把直角引号转成弯引号、插入软连字符、加全角空格，这些都不是标准 UTF-8 可控字符
- JS 字符串里拼 HTML 时，
"《"没问题，但"\u12304"要确保 JS 文件本身也是 UTF-8 编码，否则 \u 后面的数字会被当乱码处理
最容易被忽略的是：前后端联调时，API 返回的 JSON 字段值如果已含 < 这种双重转义，前端再塞进 innerHTML 就直接显示源码。真正的安全链路是——传输用原始字符串 + 前端用 textContent 或框架的安全插值，而不是靠编码数量堆砌。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
