mysql 表和字段必须显式指定 utf8mb4，因 utf8 最多存 3 字节字符，而 emoji 需 4 字节，否则插入会截断、乱码或报错；需同步配置表、字段、连接字符串、服务端参数及 orm。
MySQL 表和字段必须显式指定 utf8mb4，utf8 不行
MySQL 的 utf8 实际是阉割版，最多存 3 字节字符，而 Emoji（如 ?、??）需要 4 字节的 UTF-8 编码。用 utf8 会导致插入截断、乱码或报错 Incorrect string value。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 建表时明确指定字符集和排序规则：
CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(255) ) CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
- 已有表需用
ALTER TABLE修改：ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 别只改表，还要确认字段级定义——有时表默认是
utf8mb4，但某个VARCHAR字段仍被手动设为utf8，得单独MODIFY COLUMN
Go 数据库连接字符串要加 charset=utf8mb4 参数
即使数据库、表、字段全设对了，Go 的 database/sql 驱动（比如 mysql 或 mysqldb）默认不会启用 4 字节支持。不加参数，驱动仍按 utf8 解析，写入时会静默截断或报错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 DSN 中强制声明：
user:pass@tcp(127.0.0.1:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
- 如果用
github.com/go-sql-driver/mysql，charset=utf8mb4是必须项；漏掉它，哪怕数据库配置全对，Go 写入 Emoji 仍可能变成??? - 验证是否生效：连上后执行
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三个值都应为utf8mb4
json.Marshal 默认不转义 Emoji，但前端渲染可能出问题
Go 的 json.Marshal 对 Unicode 字符（包括 Emoji）直接输出原始 UTF-8 字节，不转义。这本身没错，但若响应头没设对、或前端没声明 UTF-8 解码，就会显示方块或问号。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保 HTTP 响应头包含：
w.Header().Set("Content-Type", "application/json; charset=utf-8") - 避免手动用
strings.ToValidUTF8或正则过滤 Emoji——除非业务强要求禁用，否则纯属自找麻烦 - 测试时别只看
curl输出：终端编码可能不一致，优先用浏览器开发者工具看 Response Body 的原始字节，或用hexdump -C确认是否真含f0 9f...这类 4 字节序列
ORM（如 GORM）需额外开启 utf8mb4 支持
GORM v2 默认不自动继承连接字符串里的 charset 设置，且其迁移（AutoMigrate）生成的表可能仍用 utf8，尤其在未指定 SetupJoinTable 或字段 tag 的情况下。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化 GORM 时显式传参：
db, _ := gorm.Open(mysql.Open(dsn + "&charset=utf8mb4"), &gorm.Config{}) - 字段 tag 中加入
charset:utf8mb4（GORM v2 支持）：type User struct { Name string `gorm:"column:name;type:varchar(255);charset:utf8mb4"` } - 别依赖
DefaultStringSize或全局NowFunc——它们和字符集无关，加了也没用
最常被忽略的是：MySQL 服务端配置里的 collation-server 和 character-set-server 必须是 utf8mb4，否则新连接可能 fallback 到 utf8。哪怕你 DSN 写对了、表也改好了，只要这个没调，某次重启后就突然又出问题。
