MySQL字段COMMENT中文乱码需同时对齐连接层与建表字符集：建表用DEFAULT CHARSET=utf8mb4，连接时指定--default-character-set=utf8mb4或charset=utf8mb4，COMMENT内容须为真实UTF-8字节而非Unicode转义；Django verbose_name须用_()包裹并走makemessages流程；PostgreSQL写COMMENT前需SET client_encoding='UTF8'；团队应以代码为注释唯一信源，通过脚本同步至数据库并CI校验。
MySQL 字段 COMMENT 里中文乱码怎么办
直接改数据库字符集不解决问题，关键在连接层和建表语句的双重编码对齐。很多团队踩坑是因为只调了 character_set_server，却没管客户端连接时的 charset 参数。
- 建表时必须显式指定表级字符集：
CREATE TABLE ... DEFAULT CHARSET = utf8mb4，不能依赖服务器默认值 - 连接 MySQL 时，驱动或命令行要加
--default-character-set=utf8mb4（CLI）或配置charset=utf8mb4（如 Python 的pymysql.connect()） -
COMMENT内容本身不能含裸 Unicode 转义（比如\u4f60\u597d），得是真实 UTF-8 字节；否则即使存进去了，SHOW CREATE TABLE里也会显示为问号或 Mojibake - 验证是否生效：执行
SELECT TABLE_COMMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'xxx'，结果应为可读中文，而非十六进制或乱码
Django Model 的 verbose_name 怎么支持多语言
靠硬编码字符串不行，必须走 gettext 流程，否则上线后没法热切换、也无法被翻译团队提取。常见错误是把 verbose_name 写成普通字符串，而不是用 _() 包裹。
- 在 model 字段定义中使用
verbose_name=_('用户名')，注意导入：from django.utils.translation import gettext as _ - 项目根目录运行
django-admin makemessages -l zh_Hans -l en，确保LOCALE_PATHS配置正确且USE_I18N = True - 字段注释不会自动进 .po 文件——必须让字符串出现在 Python 代码里且被
_()调用，模板里的{% trans %}不影响模型元数据 - 生产环境加载翻译前，确认
LANGUAGE_CODE和请求头Accept-Language匹配，否则verbose_name回退到源语言（通常是英文）
PostgreSQL 的 COMMENT ON COLUMN 怎么安全写入非 ASCII 字符
PostgreSQL 本身对 COMMENT 没有编码限制，但 psql 客户端默认可能用错编码，导致入库即损坏。问题常出现在 CI 脚本或自动化部署中。
- 执行前先确认会话编码：
SHOW client_encoding，如果不是UTF8，立刻执行SET client_encoding = 'UTF8' - 避免在 shell 脚本里拼接 SQL 字符串，尤其含中文时；推荐用
psql -v ON_ERROR_STOP=1 --set=comment_str="'用户昵称'" -f migrate.sql，再在 SQL 里用:comment_str插值 - 如果用 ORM（如 SQLAlchemy），不要手动拼
COMMENT ON COLUMN，改用Comment对象或方言扩展，否则容易漏转义单引号 - 验证方式：查
pg_description表：SELECT description FROM pg_description JOIN pg_class ON pg_class.oid=pg_description.objoid WHERE objsubid = 1 AND relname = 'users'
团队协作时怎么让数据库注释和代码注释保持同步
没人会手动去两边改，必须靠机器生成+约定流程。最可靠的方式是把字段描述“唯一信源”放在代码里，再反向导出到数据库和文档。
- 在 Django Model 或 SQLAlchemy 的
__doc__或自定义属性（如field_desc）里写结构化描述，例如：username = Column(String, doc="登录账号，唯一，长度≤32") - 写一个轻量脚本，用 AST 解析 Python 文件，提取字段 docstring，再调用
COMMENT ON COLUMN或 Django 的db_table.comment更新数据库 - 禁止直接在数据库里改 COMMENT —— 这类修改无法纳入版本控制，下次迁移脚本一跑就覆盖掉
- CI 流程中加入校验步骤：对比当前代码注释与数据库实际 COMMENT，不一致则报错，阻断发布
多语言注释最难的不是技术实现，而是让所有人接受「注释是代码的一部分」，而不是文档附属品。一旦开始手写 SQL COMMENT 或绕过 i18n 流程加中文，后续就很难拉回来。
