状态常量是系统开发中经常要处理的一类数据，它们数量有限、取值固定，例如订单状态、支付结果、用户角色、审核状态等。如果直接用 int 或 String 散落在代码中，很容易出现魔法值、拼写错误、类型错误等问题。enum 枚举类可以把这些有限且固定的状态集中管理，给状态赋予类型、行为和数据。本文将围绕 Java 中 enum 的使用方式，说明如何从定义到持久化再到业务流转，系统化地管理状态常量。
一、为什么状态常量要用枚举而不是普通常量
在早期代码或快速原型中，状态通常被定义为整型常量或字符串常量。比如订单模块里可能会写 public static final int ORDER_STATUS_UNPAID = 0;、public static final int ORDER_STATUS_PAID = 1;，业务逻辑里直接判断 if (status == 0)。这种方法看似简单，但问题很多：一是类型不安全，调用方可以传入任意整数，编译器和运行时都不会阻止错误的状态值；二是语义不清晰，0、1、2 这类数字本身没有业务含义，阅读代码时需要频繁查找常量定义；三是集中管理困难，相关的状态描述、编码、展示文案散落在不同类和配置文件中，修改时容易遗漏。
字符串常量稍好一些，至少 ORDER_STATUS_UNPAID = "unpaid" 比数字更直观，但它同样没有编译期约束。调用方可能把一个普通的字符串赋给状态字段，例如 "Unpaid" 和 "UNPAID" 被认为是两个不同的值，但业务上它们表示同一种状态。此外，字符串比较、排序、序列化和数据库存储都会引入额外处理成本。
enum 枚举最大的价值在于把一组有限且固定的常量变成一个真正的类型。编译器会检查赋值是否来自枚举定义，IDE 能给出候选补全，重构时也能通过引用分析找出所有使用位置。相比普通常量，枚举还可以携带字段、方法和构造逻辑，让状态不只是数据，而是包含行为和约束的对象。
二、从基础枚举到带编码和描述的状态枚举
Java 中定义一个枚举很简单：
public enum OrderStatus {
PENDING_PAYMENT,
PAID,
SHIPPED,
COMPLETED,
CANCELLED
}
这样就能用 OrderStatus.PENDING_PAYMENT 表示待支付状态。不过真实业务往往还需要数字编码、展示文案、是否可用于退款等属性。这时可以在枚举中加入字段和构造函数：
public enum OrderStatus {
PENDING_PAYMENT(10, "待支付"),
PAID(20, "已支付"),
SHIPPED(30, "已发货"),
COMPLETED(40, "已完成"),
CANCELLED(50, "已取消");
private final int code;
private final String desc;
OrderStatus(int code, String desc) {
this.code = code;
this.desc = desc;
}
public int getCode() {
return code;
}
public String getDesc() {
return desc;
}
public static OrderStatus fromCode(int code) {
for (OrderStatus item : values()) {
if (item.code == code) {
return item;
}
}
throw new IllegalArgumentException("未知状态编码: " + code);
}
}
这里的 code 是给数据库、接口或前端使用的稳定数字编码，desc 是中文展示文案。fromCode 方法可以根据编码反向解析出枚举实例。与散落的常量相比，状态描述和编码被绑定在一起，不会再出现代码里判断 status == 10 却不知道 10 代表什么的问题。
还可以增加一些判断方法，例如：
public boolean isFinished() {
return this == COMPLETED || this == CANCELLED;
}
public boolean canRefund() {
return this == PAID || this == SHIPPED;
}
这些方法把与状态相关的业务规则放在枚举内部，调用方只需要写 status.isFinished()，而不必写复杂的条件表达式。这比在服务层写 status == OrderStatus.COMPLETED || status == OrderStatus.CANCELLED 更直观，也便于统一维护。
三、枚举状态在持久层与接口层的使用
把状态存入数据库时，通常不会直接存枚举对象，而是存编码或名称。常见做法有三种：存 name()、存 ordinal() 或存自定义 code。存名称可读性较好，但如果后续要调整枚举名就会影响库中数据；存 ordinal 最不可取，因为枚举项插入新值时序号可能变化，导致历史数据错乱。因此推荐使用自定义的数字编码或短字符串编码，并且将编码与数据库列类型保持一致。
在 MyBatis 中，可以通过类型处理器实现枚举与编码的自动转换。例如自定义一个 EnumTypeHandler，在写入时调用 getCode()，读取时调用 fromCode()。如果不想写通用的处理器，也可以在实体类中使用 Integer 或 String 存状态码，再通过一个单独的转换层与枚举互相转换。关键是转换逻辑要集中，不要让每个 DAO 都自己写一遍 codeToStatus。
在前后端交互层面，建议后端接口返回稳定的状态编码和对应的描述。比如订单详情接口可以返回 { "status": 20, "statusDesc": "已支付" }，而不是只返回 PAID 或 2。前端根据编码做判断，描述用于展示。即使描述文案将来需要修改，也只改枚举里的 desc，接口结构和前端判断逻辑不受影响。
public class OrderResponse {
private Long orderId;
private Integer status;
private String statusDesc;
public static OrderResponse from(Order order) {
OrderResponse resp = new OrderResponse();
resp.orderId = order.getId();
resp.status = order.getStatus().getCode();
resp.statusDesc = order.getStatus().getDesc();
return resp;
}
}
如果使用 JSON 框架如 Jackson，也可以注册自定义序列化器，让枚举直接输出编码或完整对象。但要注意：如果默认使用 name() 序列化，前端会拿到 PAID 这类英文枚举名，耦合性较高，不建议作为长期方案。
四、利用枚举管理状态流转，减少散落的 if-else
状态管理不只是存值和取值，更重要的是控制状态之间的合法流转。例如订单状态只能从待支付变更为已支付或已取消，已支付可以变更为已发货，但不能直接变成已完成。把流转规则写在 service 里容易造成大量 if-else 嵌套，并且规则可能在不同方法中重复。
可以在枚举中定义一组允许的目标状态，并提供 canTransitionTo 方法：
import java.util.EnumMap;
import java.util.EnumSet;
import java.util.Map;
import java.util.Set;
public enum OrderStatus {
PENDING_PAYMENT(10, "待支付"),
PAID(20, "已支付"),
SHIPPED(30, "已发货"),
COMPLETED(40, "已完成"),
CANCELLED(50, "已取消");
private final int code;
private final String desc;
OrderStatus(int code, String desc) {
this.code = code;
this.desc = desc;
}
public int getCode() {
return code;
}
public String getDesc() {
return desc;
}
private static final Map<OrderStatus, Set<OrderStatus>> ALLOWED_TRANSITIONS =
new EnumMap<>(OrderStatus.class);
static {
ALLOWED_TRANSITIONS.put(PENDING_PAYMENT, EnumSet.of(PAID, CANCELLED));
ALLOWED_TRANSITIONS.put(PAID, EnumSet.of(SHIPPED, CANCELLED));
ALLOWED_TRANSITIONS.put(SHIPPED, EnumSet.of(COMPLETED));
ALLOWED_TRANSITIONS.put(COMPLETED, EnumSet.noneOf(OrderStatus.class));
ALLOWED_TRANSITIONS.put(CANCELLED, EnumSet.noneOf(OrderStatus.class));
}
public boolean canTransitionTo(OrderStatus target) {
Set<OrderStatus> allowed = ALLOWED_TRANSITIONS.get(this);
return allowed != null && allowed.contains(target);
}
public void validateTransitionTo(OrderStatus target) {
if (!canTransitionTo(target)) {
throw new IllegalStateException(
"订单状态不允许从 " + this.desc + " 变更为 " + target.desc
);
}
}
}
上面代码在枚举类内部用 EnumMap 保存每个状态允许流转到的目标状态集合，EnumSet 用来存放目标状态。业务层更新状态时先调用 currentStatus.validateTransitionTo(newStatus)，校验通过才执行更新。这样规则集中在枚举里，所有调用方天然受限，不会出现某个服务漏掉校验的情况。
当然，状态流转规则也可以放到领域服务或状态机框架中，但当系统状态数量有限、规则不复杂时，直接放在枚举里是最简单、最内聚的方案。如果流转规则变得非常复杂，例如需要根据订单类型、支付方式动态决定下一状态，再考虑引入外部状态机。
五、枚举与集合、比较和序列化中的注意事项
使用枚举时有一些容易踩坑的地方。不要用 ordinal() 作为数据库存储值，前面已经提到，因为枚举项插入新值时序号会整体后移。也不要依赖 name() 与前端或数据库强绑定，名称更偏向代码可读性，而不是业务契约。真正对外暴露的应该是自定义 code 或短字符串编码。
枚举适合用 EnumSet 和 EnumMap 来存放，它们比普通的 HashSet 和 HashMap 性能更好，内部基于位向量或数组实现。例如需要保存一组可见状态时，可以写：
Set<OrderStatus> visibleStatuses = EnumSet.of(
OrderStatus.PENDING_PAYMENT,
OrderStatus.PAID,
OrderStatus.SHIPPED
);
这样写比 new HashSet<>() 更简洁，并且类型安全。比较两个枚举值时直接用 == 即可，因为每个枚举实例在 JVM 中都是单例，不必使用 equals 或 compareTo。这个细节看似微小，却能让代码更简洁、更少出现空指针风险。
序列化方面，如果使用 Jackson 或 Gson，默认行为通常是把枚举序列化为 name()。如果希望输出中文描述或数字编码，需要配置自定义序列化器或使用 @JsonValue 注解。也可以直接在 DTO 层转换为整型或字符串，避免让第三方序列化库去过深地绑定枚举结构。