不推荐用Enum.ordinal()作为变量索引映射业务处理器，因其是编译期生成的脆弱序号，随声明顺序变更而静默错位，易引发状态路由错误；应改用显式字段、静态映射表或枚举内建方法引用。
不推荐用 enum.ordinal() 作为变量索引去映射业务处理器——它脆弱、隐式、易出错，且在高性能状态机中反而拖累可维护性与安全性。
ordinal() 的本质是编译期序号，不是设计契约
ordinal() 是枚举常量在源码中声明顺序的自动编号（从 0 开始），它不参与类型系统校验，也不受 IDE 或编译器保护。一旦调整枚举顺序（比如插入新状态、重排、注释掉某项），所有依赖 ordinal 的映射逻辑会静默错位，引发难以追踪的状态路由错误。
- 例如：
OrderStatus.CREATED.ordinal() == 0，但若后续把CREATED移到第 3 位，映射数组下标 0 就指向了别的状态 - JVM 不保证不同编译环境或版本下 ordinal 稳定（虽实际极少变，但规范未承诺）
更安全高效的替代方案：静态映射表 + 方法引用
用 private static final 数组或 Map 显式绑定处理器，配合枚举自身的字段初始化，既保留 O(1) 查找性能，又杜绝序号漂移风险：
public enum OrderState {
CREATED(() -> new CreatedHandler()),
PAID(() -> new PaidHandler()),
SHIPPED(() -> new ShippedHandler());
private final Supplier<StateHandler> handlerFactory;
OrderState(Supplier<StateHandler> factory) {
this.handlerFactory = factory;
}
public StateHandler createHandler() {
return handlerFactory.get();
}
}
调用时直接 state.createHandler().handle(event)，无索引、无反射、无 map 查找开销，JIT 还可能内联。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
若坚持数组索引，必须用显式序号字段代替 ordinal()
如需极致性能（微秒级）且接受少量样板代码，可定义 int index 字段，并在构造时硬编码赋值：
public enum PaymentMethod {
CREDIT_CARD(0),
ALIPAY(1),
WECHAT_PAY(2);
public final int index; // 显式、不可变、文档化
PaymentMethod(int index) {
this.index = index;
}
}
// 预分配处理器数组（大小固定、无装箱）
private static final PaymentHandler[] HANDLERS = new PaymentHandler[3];
static {
HANDLERS[CREDIT_CARD.index] = new CreditCardHandler();
HANDLERS[ALIPAY.index] = new AlipayHandler();
HANDLERS[WECHAT_PAY.index] = new WechatPayHandler();
}
// 使用：HANDLERS[method.index].process(...) —— 安全、快速、意图清晰
补充提醒：状态机真正的性能瓶颈通常不在这里
高频状态流转中，更值得关注的是：
- 避免每次创建处理器实例（复用单例或对象池）
- 减少锁竞争（用无锁队列、CAS 状态更新）
- 事件处理路径是否含 I/O 或同步阻塞调用
- 状态迁移规则是否用 switch 或查表而非反射/字符串匹配
为省几纳秒而牺牲健壮性，得不偿失。现代 JVM 对枚举方法调用优化极好，state.getHandler() 的开销远低于一次缓存未命中或 GC 停顿。
