必须将服务端、连接层、表结构、字段定义四者全部对齐到utf8mb4，缺一不可；仅改其中一两处仍会报错，需通过show variables和show create table逐层排查，重点检查character_set_client、connection、results、server及字段级character set定义。
必须把服务端、连接层、表结构、字段定义四者全部对齐到 utf8mb4，缺一不可。只改其中一两处，错误照常报。
查清当前字符集在哪一环掉链子
执行 SHOW VARIABLES LIKE 'character_set%';，重点关注这四个值：character_set_client、character_set_connection、character_set_results、character_set_server。只要有一个是 utf8（不是 utf8mb4），就可能触发 Incorrect string value。再用 SHOW CREATE TABLE your_table; 看字段定义里是不是还写着 CHARACTER SET utf8 —— 很多表看着“支持中文”，其实连 emoji 的第一个字节都存不下。
ALTER DATABASE 和 ALTER TABLE 不等于字段升级
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; 只影响后续新建的表；ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 会重建整张表，但旧字段如果之前是 utf8，它的定义不会自动刷新，仍可能被客户端按老规则解析。真正生效的是逐字段修改：ALTER TABLE table_name MODIFY COLUMN content VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。注意：必须重写完整字段定义（类型、长度、是否 NULL、默认值等），漏掉一个约束，字段就可能被重置为非预期状态。
应用连接不声明 utf8mb4 就白搭
MySQL 服务端全配成 utf8mb4，但 PHP 用 PDO 连接时没加 PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"，Python 用 PyMySQL 没传 charset='utf8mb4'，Java JDBC URL 缺 useUnicode=true&characterEncoding=utf8mb4，那连接建立时协商的仍是 utf8，服务端就按三字节规则截断数据。这不是配置遗漏，是协议层根本没谈拢。环境变量、配置文件里设了也没用，必须在连接初始化时显式声明。
十六进制错误码直接暴露问题根源
报错里出现类似 '\xF0\x9F\x98\x80' 或 '\xF0\x9F\x90\xA6' 这种四字节序列，基本可锁定是 emoji；而 '\xE6\x88\x91' 或 '\xE5\xBC\xA0' 是常见汉字 UTF-8 编码，说明连基础中文都没走通 utf8mb4 链路，大概率是客户端或字段层卡在 utf8。别猜，直接用这串十六进制反查字符，就能确认它到底需不需要 4 字节支持——这是最硬的判断依据。
最容易被忽略的是连接层和字段定义的双重绑定：即使表默认字符集改了，已有字段的 DDL 定义不变，客户端连接又没声明 utf8mb4，两条路同时失效，错误就稳稳复现。动手前先跑一遍四层检查，比反复试改更省时间。
