枚举中声明抽象方法并由各常量用{}块实现，是类型安全、编译强制检查的差异化策略；需配合私有字段复用共性数据，方法签名须稳定，适用于状态机等有限内聚场景。

直接在枚举里声明抽象方法，让每个常量用 {} 块实现各自逻辑，是最简洁、类型安全的差异化方案。编译器强制检查，漏写一个就报错，彻底避免运行时行为缺失。

必须每个常量都实现抽象方法

枚举类中声明抽象方法后，所有常量都得在大括号内覆盖它——这不是可选项，是编译期硬约束：

• 写法必须是 ADD { @Override int apply(int a, int b) { return a + b; } }，不能写成 ADD; { ... }
• 少实现任意一个常量，编译直接失败，提示类似 enum constant SUBTRACT must implement abstract method apply(...)
• 枚举类本身不用加 abstract 修饰符，但抽象方法声明后不能有方法体（空花括号也不行）

结合私有字段复用共性数据

纯靠 {} 写逻辑容易重复。把不变的信息（如状态码、描述、图标名）抽到构造器和私有字段中，让抽象方法专注“变”的部分：

• 声明 private final int code; private final String desc;
• 每个常量初始化时传参：PENDING(100, "待支付") { ... }
• 抽象方法体内可自由访问 this.code 或拼接字符串：return this.code + ": " + this.desc;

抽象方法要设计得足够稳定

参数和返回值一旦定下，所有常量必须严格一致。改签名等于重构整个枚举：

• 不支持协变返回（比如有的返回 int，有的返回 Optional）
• 不能靠重载增加不同参数的方法，Java 不允许枚举里同名多签
• 需要额外上下文？别塞进方法参数，而是作为调用方传入的参数，或封装进独立的 Context 对象传给抽象方法

适合场景与明显边界

这种写法不是万能的，关键看是否匹配它的天然属性：

• 适合：状态机（订单/审核/设备状态）、运算符、消息类型、权限等级等固定、有限、逻辑内聚的策略集合
• 不适合：行为复杂（含远程调用、事务、状态缓存）、需运行时动态注册、或 80% 逻辑雷同仅个别例外的情况
• 注意：枚举实例在类加载时初始化，{} 中的代码会立即执行，避免放有副作用的操作