遇到MySQL的1366错误，十有八九是字符集没对齐。说白了，就是连接层的character_set_client和字段级的排序规则没统一成utf8mb4，导致中文字段名、注释或默认值在发送时被错误编码，然后被MySQL拒之门外。
保存失败，其实不是表结构本身有问题，而是Na vicat在提交修改时，把中文字段名、注释或默认值按错误编码发给了MySQL，服务端要么直接拒收，要么静默截断。关键就得让alter table语句里的中文字节不被损坏。
设计表界面输入中文后点“保存”弹错：Incorrect string value
典型的ERROR 1366，表面上看是数据被拒，根子其实是连接层的字符集没和字段对齐。常见于字段的COMMENT、DEFAULT值或列名里带了中文，但连接层character_set_client没设对。
- 右键表 → “设计表”，输完中文别急着点保存，先跑一条
SET NAMES utf8mb4;（在同一个查询窗口里执行） - 确认当前连接已启用
utf8mb4：右键连接 → 编辑连接 → 高级 → 勾选“使用自定义字符集”并设为utf8mb4 - 如果用的是Na vicat 16+，检查一下是否误开了SQL预处理：工具 → 选项 → SQL 编辑器 → 取消勾选“启用 SQL 预处理”（否则
'用户姓名'会被转成'u7528u6237u59d3u540d'再发出去）
字段名/注释能显示中文，但保存后变成问号或空
表面上是设计表界面的问题，实际上是字段级字符集没继承上来。就算库和表都设了utf8mb4，字段仍然可能沿用latin1的COLLATION。
- 跑一句
SHOW CREATE TABLE `your_table`;，看看字段定义里有没有CHARACTER SET latin1，或者干脆缺了COLLATE - 手动修正字段：比如
MODIFY COLUMN name VARCHAR(50) COMMENT '姓名' CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 建新表时，在“设计表”界面每列右侧的“备注”栏输完中文后，记得点击该列 → 展开“高级” → 检查“排序规则”是否为
utf8mb4_unicode_ci（而不是latin1_swedish_ci）
保存按钮灰掉或无响应，但没报错
这种情况不是编码问题，而是Na vicat检测到了潜在冲突——比如字段名里混进了全角空格、中文括号（）或者不可见控制字符，它会拒绝提交，但不会提示具体原因。
- 把字段名、注释复制到纯文本编辑器（比如VS Code），打开显示不可见字符功能（
Ctrl+Shift+P→ “Toggle Render Whitespace”），检查有没有全角符号 - 尽量避免直接从微信、Word粘贴中文；改用记事本中转，或者手动敲写
- 如果开了Na vicat的“自动格式化”，建议关掉：工具 → 选项 → SQL 编辑器 → 取消“格式化 SQL 时自动修正编码”
最容易被忽略的，其实是字段级的COLLATE设置——它的优先级比表级字符集更高，而且不会在设计表界面显式标出来，必须靠SHOW CREATE TABLE才能确认。一旦某列用了latin1_swedish_ci，哪怕整库都是utf8mb4，存中文照样失败。
