最简有效方式是<meta charset="UTF-8">写在<head>最前，但需文件实际编码、HTTP响应头、meta声明三者统一，缺一不可；否则仍会乱码。
直接在 <head> 里写 </meta charset="UTF-8"> 是最简、最有效的方式，但仅靠这行代码不能保证中文不乱码——它只是“声明”，不是“强制”。真正起作用的是三者协同：文件实际编码、HTTP 响应头、meta 声明。缺一不可。
为什么 <meta charset="UTF-8"> 有时没用？
常见现象：写了这行，页面还是显示方块或问号。
- 浏览器根本没读到它：它被放在
<title>之后、或者被注释掉了，甚至前面有 BOM 冲突（比如 UTF-8 with BOM 放在<!DOCTYPE html>前面） - 服务器发来的 HTTP 响应头优先级更高，比如 Nginx 返回了
Content-Type: text/html; charset=GBK，浏览器就直接忽略meta - 文件本身不是 UTF-8 编码：你在 Notepad++ 里选了 “UTF-8”，但没勾 “BOM”，保存后其实是 UTF-8 without BOM；而某些旧环境（如 IE 本地双击打开
file://）会误判为 ANSI/GBK - 开发时用了 PHP/Node.js 拼接 HTML，但 PHP 文件自己是 GBK 编码，
echo "<meta charset=\"UTF-8\">"输出的其实是乱码字节，meta 标签本身已损坏
如何确认当前生效的编码？
别猜，用 Chrome DevTools 实锤：
- F12 → Network → 刷新页面 → 找到主 HTML 请求（如
index.html）→ 点开 → 查看 Response Headers 中的Content-Type值 - 如果值是
text/html; charset=UTF-8，说明服务器配置正确；如果是gbk或没带charset，问题出在服务端 - 再点开 Response 标签页，直接看原始 HTML 内容是否可读中文 —— 如果这里已经是乱码，说明文件保存编码错了，meta 再对也白搭
- 最后检查
document.characterSet：在 Console 里输入该变量，返回值应为"UTF-8"
VS Code / Notepad++ 怎么保存为真正有效的 UTF-8？
关键不是“选 UTF-8”，而是“带 BOM”或“不带 BOM”要匹配使用场景：
立即学习“前端免费学习笔记（深入）”；
- VS Code：右下角状态栏点击当前编码（如
UTF-8）→ 选Save with Encoding→ 明确选UTF-8 with BOM（尤其用于本地双击测试） - Notepad++：菜单栏
编码→转为 UTF-8-BOM 编码→ 再保存 - Sublime Text：File → Save with Encoding → UTF-8（它默认不带 BOM，但现代浏览器基本兼容）
- ⚠️ 注意：BOM 是三个字节
EF BB BF，必须紧贴文件开头，不能有任何空格或换行在它前面；否则<!DOCTYPE html>解析失败，整个页面变白屏
服务端怎么配 Content-Type？
本地测试没问题，上线后乱码？八成是服务端没设 charset：
- Nginx：在
server或location块里加charset utf-8;（注意不是charset UTF-8;，小写） - Apache：在站点根目录放
.htaccess，内容为AddDefaultCharset UTF-8 - Express（Node.js）：在
res.send()前加res.set('Content-Type', 'text/html; charset=utf-8'); - PHP：不要依赖
header("Content-Type: text/html; charset=utf-8");，更稳妥的是确保 PHP 文件自身是 UTF-8 编码，并在输出 HTML 前不 echo 任何非 UTF-8 字符
最容易被忽略的点：文件编码和 meta 声明必须严格一致；而服务端响应头一旦存在，就会覆盖 meta。调试时先看 Network 面板里的 Response Headers，再查 Response 内容本身，最后才看 HTML 源码 —— 顺序错了，90% 的时间都花在冤枉路上。
