富枚举通过静态中转类实现spring bean注入，本质是绕过jvm枚举初始化限制：定义@component静态内部类+@postconstruct缓存bean，枚举静态块从中获取；或监听contextrefreshedevent主动赋值，避免构造器npe、线程安全及生命周期问题。
富枚举项直接绑定Spring容器中的Bean实例，本质是让枚举不只是“值的集合”，而是具备行为、依赖和上下文感知能力的活跃对象。这确实能打破传统贫血枚举（仅含常量字段+简单getter）的局限，但关键在于：枚举类本身不能被Spring直接管理（因JVM在类加载阶段就初始化所有枚举实例），所以不能用@Autowired直接注入——必须绕过这个限制，靠静态持有+延迟赋值实现“伪注入”。
用静态内部类做Bean中转站
这是最稳妥、无副作用的方式。核心思路是把Spring管理的Bean，通过一个Spring托管的静态容器类，提前取出并缓存到静态变量中，再由枚举静态块或方法调用该变量。
- 定义一个
@Component静态内部类（或独立工具类），用@PostConstruct把目标Bean存入static字段 - 枚举中声明同类型
static引用，并在static块或init()方法里从容器类取值 - 确保该内部类在Spring上下文刷新后已初始化（通常自动满足）
在枚举方法中调用Bean逻辑
不把Bean塞进枚举字段，而是在枚举方法体内通过中转类获取并使用。这样更轻量，也避免了枚举实例持有可能失效的引用。
- 枚举方法保持
abstract，每个枚举项重写具体实现 - 实现中调用类似
MyBeanContainer.getMyService().doSomething() - 适合一次性操作、无状态调用场景，如事件分发、策略执行
配合@PostConstruct在枚举构造后注入
部分项目会尝试在枚举内部定义@PostConstruct方法，但这其实无效——因为枚举实例不是Spring Bean，@PostConstruct不会被Spring容器触发。真正可行的是：在枚举外建一个独立的初始化Bean，监听上下文就绪事件，再主动给枚举静态字段赋值。
- 创建一个
@Component类，监听ContextRefreshedEvent - 在监听方法中调用枚举提供的
setXxxService()静态方法 - 枚举需暴露安全的setter（建议加
synchronized或双重检查）
避免踩坑的关键细节
富枚举不是万能解药，用错反而引入隐式耦合和启动时序问题。
- 不要在枚举构造器里访问未初始化的Bean引用（极易NPE）
- 避免在枚举字段中存非线程安全Bean（如
RestTemplate需注意并发） - 若Bean有生命周期（如带
@Scope("prototype")），每次都要重新获取，不能复用静态引用 - 单元测试时需手动触发Bean注入，否则枚举方法会空指针
