浏览器乱码主因是HTTP响应头、文件保存编码与meta charset三者未对齐；需优先确保响应头Content-Type含charset，再确认文件无BOM且meta置于head最前。
浏览器显示乱码，八成是编码设置没对齐——meta charset只是其中一环，单独写它不等于万事大吉。
为什么写了
这个标签只在浏览器找不到更权威的编码声明时才生效。一旦 HTTP 响应头里有 Content-Type: text/html; charset=GBK，浏览器就直接忽略 meta，按 GBK 解码，结果就是一堆 和乱码字。
- 用 Chrome DevTools 的 Network → Response Headers 查看实际返回的
Content-Type字段，别信源码里写的 -
meta必须放在最开头（<script></script>里 - 如果后端用 Java/PHP/Node.js 输出 HTML，得先确保响应头已设好，否则
meta是“补救措施”，不是“兜底方案”
后端必须同步设置 Content-Type 响应头
前端写的 meta 是被动 fallback，后端发出去那一刻，编码就定死了。
- Java Servlet：
response.setContentType("text/html; charset=UTF-8")必须在getWriter()之前调用 - PHP：
header('Content-Type: text/html; charset=UTF-8');必须在任何输出（包括空格、BOM）之前执行 - Express（Node.js）：
res.set('Content-Type', 'text/html; charset=utf-8')或res.writeHead(200, {'Content-Type': 'text/html; charset=utf-8'}) - Apache：在
.htaccess加AddDefaultCharset UTF-8，或配置Header set Content-Type "text/html; charset=UTF-8" - Nginx：在
server或location块加charset utf-8;
编辑器保存格式和 BOM 是隐形坑
VS Code 默认存为 UTF-8 无 BOM，但 Notepad++ / Sublime Text 默认可能带 BOM；而 BOM（EF BB BF）若出现在 之前，会破坏 HTML 解析，导致 meta charset 失效或页面白屏。
- 用 VS Code 打开 HTML 文件，右下角查看编码标识，点击后选 Save with Encoding → UTF-8（不是 “UTF-8 with BOM”）
- 用十六进制编辑器（如 HxD）检查文件开头：要是
EF BB BF，说明有 BOM；正常应以3C 21 44 4F 43（即）起始 - HTML5 规范明确要求
charset值必须是"UTF-8"（连短横都不能少），写成utf8、UTF_8或utf-8（小写 u）都可能被某些旧解析器拒绝
它不解决乱码，但能避免某些字体回退、标点挤压、数字排版异常等问题，尤其在中英文混排时。
-
lang属性必须写在标签上，写在或其他元素里无效 - 值要规范：
zh-CN（简体中文）、zh-TW（繁体中文台湾）、en-US，不能只写zh或cn - 不要用已废弃的
meta http-equiv="Content-Language"，它既不控制编码，也不被现代浏览器尊重
真正起作用的是三者对齐：HTTP 响应头指定的 charset、HTML 文件实际保存的编码格式、meta charset 声明的值——缺一不可，错一个就可能出问题。最稳妥的做法是关掉编辑器的 BOM、后端硬设响应头、再加一行 meta 作双重保险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
