MySQL中需用CASE WHEN按字符串匹配显式映射ENUM值，如WHEN 'active' THEN '启用'，不可用数字匹配，且必须含ELSE防NULL；PostgreSQL推荐用VIEW封装CASE逻辑复用；MyBatis可通过TypeHandler在Java层统一转换，但WHERE和ORDER BY仍须基于原始字段。
MySQL中用CASE WHEN对ENUM字段做值映射
MySQL原生不支持ENUM值的自动翻译，必须手动映射。直接SELECT枚举列只会返回定义时的字符串（如 'active'、'inactive'），而前端或报表常需显示“启用”“停用”这类中文。最稳妥的做法是用 CASE WHEN 显式转换：
SELECT
id,
CASE status
WHEN 'active' THEN '启用'
WHEN 'inactive' THEN '停用'
WHEN 'pending' THEN '待审核'
ELSE '未知'
END AS status_label
FROM users;注意：ENUM底层虽以整数存储，但CASE必须按字符串匹配——写成 WHEN 1 THEN ... 会失效；另外，ELSE 分支不能省，否则NULL或未定义值将变成NULL，容易在报表里漏数据。
PostgreSQL中用CASE或自定义VIEW封装枚举翻译
PostgreSQL的ENUM是独立类型，查询时仍返回原始值（如 'draft'）。和MySQL类似，CASE WHEN 是最直接的方式。但更推荐把翻译逻辑下沉到VIEW里复用：
CREATE VIEW users_with_labels AS
SELECT
id,
name,
CASE state
WHEN 'draft' THEN '草稿'
WHEN 'published' THEN '已发布'
WHEN 'archived' THEN '已归档'
ELSE '其他'
END AS state_label
FROM articles;后续所有查询都可直接 SELECT * FROM users_with_labels，避免重复写CASE；若枚举值频繁变动，改VIEW比改一堆SQL更安全。别忘了给VIEW加注释说明映射规则，不然半年后自己都看不懂'archived'对应啥。
Java MyBatis里用typeHandler统一处理ENUM翻译
如果SQL层不处理，也可以交由ORM完成。MyBatis通过自定义 TypeHandler 实现数据库值与Java枚举的双向转换，同时支持在SQL查询结果中注入中文标签：
- 定义Java枚举时加
label字段和构造方法，比如ACTIVE("启用") - 写一个继承
BaseTypeHandler<statusenum></statusenum>的处理器，在getNullableResult()里根据数据库字符串查对应枚举，再调enum.getLabel() - 在Mapper XML里为字段指定
resultMap并绑定该TypeHandler
这样 SELECT status FROM user 返回的就是带中文标签的对象属性，不用每条SQL都写CASE。但要注意：该方式只影响Java端取值，原始SQL结果仍是英文，导出CSV或给其他系统用时仍需额外处理。
避免在WHERE条件里对翻译后字段做筛选
有人会想“既然SELECT能翻译，那WHERE也能用中文筛选”，比如 WHERE status_label = '启用' —— 这会报错，因为 status_label 是计算列，不是真实字段。正确做法只有两种：
- WHERE仍用原始值：
WHERE status = 'active' - 或者用子查询/CTE先算出label，再在外层筛选（性能差，不推荐）
另一个坑是排序：按 status_label ORDER BY 会导致全表计算+文件排序，远慢于直接 ORDER BY status。真正需要按中文排序时，应在ENUM定义时按业务顺序排列值（如 ENUM('draft','active','inactive')），再靠数据库默认序保证一致性。
枚举翻译看着简单，但跨层（DB/ORM/前端）时最容易漏掉某一层的映射，导致“明明写了启用却查不到”。建议选一个主阵地（比如MySQL的VIEW或MyBatis的TypeHandler）集中维护，其他层尽量复用，而不是到处散落CASE语句。
