必须全链路升级为utf8mb4才能彻底解决微信小程序中emoji、生僻字插入乱码问题，因MySQL原生utf8实为utf8mb3，仅支持3字节编码，无法存储4字节Unicode字符；需同步配置服务端、连接层、数据库、表、字段及排序规则六层，缺一不可。
因为微信小程序前端会直接透传用户输入的 emoji、生僻字（如“䶮”“?”）、微信聊天截图文字，而 MySQL 原生 utf8 实际是 utf8mb3，最多只支持 3 字节编码，无法存下这些字符——插入时会静默截断或报 Incorrect string value 错误。
MySQL 的 utf8 名不副实，本质是阉割版
MySQL 从 4.1 开始实现的 utf8，是为了兼容当时主流字符（BMP 平面）而设计的 3 字节上限编码。它根本不是标准 UTF-8，连基本的 ?、❤️、?? 都存不了。直到 5.5.3 才引入真正的 utf8mb4，完整覆盖 Unicode 全码位（U+0000–U+10FFFF）。现在所有新项目必须绕过 utf8 这个别名，显式写 utf8mb4。
微信小程序场景下，utf8mb4 是保底要求
小程序里这些数据天然带 4 字节字符：
- 用户昵称/签名可能含 emoji 或方言字（如“?”“堃”）
- 收件地址栏粘贴微信聊天记录，常带复制过来的符号、换行、零宽空格
- 客服备注、物流状态描述里随手加个 ✅❌??，后端一入库就变 ? 或报错
- 微信支付回调里的
attach字段、body字段未做转义，原样落库
只改数据库字符集还不够，六层必须对齐
哪怕 character_set_server 已设为 utf8mb4，只要其中一层错配，照样乱码或丢数据：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
character_set_client：客户端声明自己发的是什么编码，小程序后端（如 Java/Node.js）连接串里必须带characterEncoding=utf8mb4 -
character_set_connection：MySQL 中间层解码用的编码，init_connect='SET NAMES utf8mb4'可强制统一 - 表/列级没显式指定
CHARACTER SET utf8mb4？旧表字段仍按建表时默认走latin1或utf8，数据已存进去就救不回来 - 排序规则别乱选：
utf8mb4_unicode_ci比utf8mb4_general_ci更准（尤其对中文排序），MySQL 8.0 起推荐utf8mb4_0900_ai_ci
迁移已有项目时最容易踩的坑
直接 ALTER DATABASE ... CHARACTER SET utf8mb4 只改了默认值，不会影响已有表和字段。真正生效要三步全做：
- 先确认
innodb_large_prefix = ON，否则VARCHAR(255)字段加索引会因 4 字节 × 255 > 767 报错 - 用
SHOW CREATE TABLE检查每张表的DEFAULT CHARSET和每个VARCHAR列的CHARACTER SET，逐个CONVERT TO CHARACTER SET utf8mb4 - 导出再导入是最稳妥的：mysqldump 加
--default-character-set=utf8mb4，且建表语句里手动替换所有utf8为utf8mb4
最常被忽略的一点：微信小程序调用云开发或自建 API 时，如果后端用了连接池（如 HikariCP），池子里的连接可能复用旧的 character_set_connection 设置，重启服务或清空连接池比改配置更管用。
