富枚举通过静态中转类实现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注入，否则枚举方法会空指针