如何从非CDI管理的简单对象中访问CDI托管的AppConfig单例？

方案1：CDI 程序式动态获取（适配成本最低） #

直接调用CDI提供的静态API获取容器内的单例，不需要给LightSource加注入注解，也不需要修改现有实例化逻辑：

import jakarta.enterprise.inject.spi.CDI;

class LightSource {
  double brightness;
  // 其余属性、方法省略

  boolean isValid() {
    AppConfig appConfig = CDI.current().select(AppConfig.class).get();
    return brightness <= appConfig.getMaxAllowedBrightness();
  }
}

• 优点：代码改动量最小，不影响现有LightSource的创建、使用逻辑
• 缺点：数据对象和CDI容器强耦合，脱离CDI环境（比如纯单元测试场景）时方法会报错，需要额外Mock容器上下文

方案2：静态持有全局配置单例（轻量解耦方案） #

利用AppConfig本身是应用级单例的特性，在容器启动时主动将实例赋值给静态变量，所有数据对象直接读取静态变量即可：
首先修改AppConfig类：

@ApplicationScoped
class AppConfig {
  private static AppConfig INSTANCE;

  // 容器启动完成后自动触发，给静态变量赋值
  public void init(@Observes StartupEvent event) {
    INSTANCE = this;
  }

  public static AppConfig getInstance() {
    return INSTANCE;
  }

  public double getMaxAllowedBrightness() { ... }
};

之后在LightSource中直接调用：

boolean isValid() {
  return brightness <= AppConfig.getInstance().getMaxAllowedBrightness();
}

• 优点：实现简单，调用成本极低，只有AppConfig和容器耦合，LightSource完全不感知容器存在
• 缺点：静态变量在单元测试时需要手动Mock/重置，多个应用部署在同一个容器的场景下可能存在类加载器冲突问题

方案3：校验逻辑抽离（推荐最佳实践） #

数据对象（POJO）的核心定位是承载数据，不应该承载依赖外部容器的业务校验逻辑，将校验逻辑单独抽为应用级的校验器Bean，由这个Bean注入AppConfig，专门负责LightSource的校验：
首先定义校验器：

@ApplicationScoped
class LightSourceValidator {
  @Inject
  AppConfig appConfig;

  public boolean isValid(LightSource lightSource) {
    return lightSource.getBrightness() <= appConfig.getMaxAllowedBrightness();
  }
}

LightSource仅保留纯数据相关逻辑：

class LightSource {
  double brightness;

  public double getBrightness() {
    return brightness;
  }
  // 其余纯数据属性、方法省略
}

所有需要校验LightSource的业务场景，直接注入LightSourceValidator调用对应方法即可。

• 优点：完全符合单一职责原则，数据对象和容器完全解耦，单元测试成本极低，可以分别对数据逻辑、校验逻辑做独立测试
• 缺点：需要调整原有调用isValid的业务代码，改为调用校验器方法

内容的提问来源于stack exchange，提问作者cuckoo