MySQL插入Emoji失败的根本原因是默认utf8（即utf8mb3）仅支持3字节编码，而Emoji需4字节，必须将服务端、数据库、表、字段及连接层全部统一设为utf8mb4并重启生效。
MySQL 字段没设 utf8mb4 会导致 Emoji 插入失败
Emoji 是四字节 Unicode 字符（如 U+1F602），而 MySQL 默认的 utf8 编码只支持最多三字节字符，实际是 utf8mb3。直接存会报错：Incorrect string value: '\xF0\x9F\x98\x82' for column 'content'。
必须把字段、表、连接、服务端全部升级到 utf8mb4：
- 建表时显式指定：
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 已有表执行：
ALTER TABLE comments CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci -
数据库连接 URL 加参数：
?charset=utf8mb4（如 Node.js 的mysql2） - 确认
my.cnf中collation-server = utf8mb4_unicode_ci且init-connect='SET NAMES utf8mb4'
React Fiber 渲染中 Emoji 被截断或显示为方块
这不是数据库问题，而是前端渲染链路中字体或编码缺失导致的视觉异常。常见于使用了不支持 emoji 的系统字体（如某些 Linux 环境下的 DejaVu Sans）或未声明 font-family 回退链。
确保 CSS 中有明确的 emoji 支持回退：
body {
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji";
}
同时检查 DOM 元素是否被意外截断（例如 text-overflow: ellipsis + white-space: nowrap 组合），Emoji 在换行/截断边界容易出问题。
Node.js 后端用 mysql2 存 Emoji 时仍报错
即使数据库配置正确，Node.js 驱动层也可能因连接初始化不完整而降级使用 utf8。
关键检查点：
- 连接选项中必须包含：
charset: 'utf8mb4'（不是utf8） - 避免在 SQL 字符串里手动拼接用户输入 —— 使用参数化查询，否则驱动可能无法自动识别编码上下文
- 若用 ORM（如 Prisma），确认其 schema.prisma 中字段类型为
String @db.VarChar(255)且数据库连接 URL 带?charset=utf8mb4 - 调试时打印
connection.config.charset确认运行时值确实是utf8mb4
Fiber 应用里从表单取 Emoji 输入后丢失或乱码
典型原因是前端未声明请求体编码，或后端未正确解析 application/json 或 application/x-www-form-urlencoded 内容。
Express 示例修复：
app.use(express.json({ limit: '10mb', type: ['application/json', 'application/csp-report'] }));
app.use(express.urlencoded({ extended: true, limit: '10mb' }));
注意：extended: true 对 urlencoded 很关键 —— 它启用 qs 库解析，能正确处理 Unicode 字符；设为 false 会用内置解析器，对 Emoji 支持不稳定。
另外，浏览器提交前可加验证：if (!/[\u{1F600}-\u{1F6FF}]/u.test(input)) {...}，但这只是辅助，不能替代后端和 DB 层的 utf8mb4 全链路保障。
最容易被忽略的是连接池复用场景：一个连接初始化为 utf8mb4，另一个没设，混用时出问题。务必统一所有连接配置，别依赖“默认”。
