乱码主因是浏览器解析时HTTP响应头、HTML实际编码、meta声明三者不一致；常见表现为中文变“锟斤拷”、emoji成方块，关键陷阱是meta标签前不能有BOM或空格，否则浏览器fallback至GBK等默认编码。
为什么写了还是乱码？
因为浏览器只看三样东西：HTTP响应头的Content-Type、HTML文件实际保存的编码、以及<meta charset="UTF-8">是否能被正确识别——三者只要有一个是GBK或latin1，就大概率出问题。常见现象包括中文显示为、emoji变成方块、console.log("你好")报Invalid or unexpected token。关键陷阱在于：<meta charset>必须出现在最开头，前面不能有任何BOM、空格、注释或<script></script>；否则浏览器可能跳过它， fallback 到系统默认编码（比如Windows记事本的GBK）。
MySQL列级字符集不一致怎么查？
表和数据库设成utf8mb4不代表万事大吉。执行以下语句检查具体字段：
SHOW CREATE TABLE users;
重点看输出中每个VARCHAR字段的定义，例如name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。如果某列写着CHARACTER SET latin1或utf8（不是utf8mb4），那就是隐患点。修复方式不是改表默认值，而是显式修改列：
ALTER TABLE users MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 必须对每个疑似字段单独执行
MODIFY或CHANGE - 避免用
CONVERT TO CHARACTER SET，它可能隐式截断4字节emoji - 改完后用
SELECT HEX(name) FROM users LIMIT 1;验证存储的是EFBBBF类UTF-8字节，不是A4A7类GBK字节
PHP PDO连MySQL时charset参数怎么写才生效？
只在DSN里加;charset=utf8mb4不够，PDO默认不强制执行SET NAMES。必须同时设置连接选项：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
$pdo = new PDO($dsn, $user, $pass, [
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci",
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);
注意点：
-
charset=utf8是错的——MySQL的utf8只支持3字节Unicode，存不了emoji；必须用utf8mb4 -
PDO::MYSQL_ATTR_INIT_COMMAND比DSN里的charset更可靠，尤其在长连接复用场景下 - 如果用Laravel等框架，确保
config/database.php中mysql配置项包含'charset' => 'utf8mb4'和'collation' => 'utf8mb4_unicode_ci'
HTML文件保存为UTF-8无BOM的实操步骤
VS Code默认新建文件是UTF-8 with BOM，而BOM（EF BB BF）会卡在<meta charset>前面，导致浏览器无法识别。正确做法：
- 打开文件 → 右下角点击编码名称（如“UTF-8 with BOM”）→ 选
Save with Encoding→ 选UTF-8（注意没有“with BOM”字样） - 保存后右下角应显示“UTF-8”，且状态栏不带BOM标识
- 用命令行验证：Linux/macOS运行
head -c 3 index.html | xxd，输出不应含ef bb bf；Windows用PowerShell：Get-Content index.html -Encoding Byte | Select -First 3 - Sublime Text/Notepad++同理，务必选“UTF-8”而非“UTF-8 with BOM”
这个细节90%的人第一次都会踩坑：文件内容、meta标签、HTTP头全对，就差这3个字节，整个页面就崩了。
