supplier构造函数注入不是替代而是增强依赖注入，将依赖创建时机推迟到首次使用时，适用于高成本、低频次、条件性组件。
Supplier 配合构造函数注入，不是替代依赖注入，而是增强它——把“依赖的创建时机”从容器初始化阶段，进一步推迟到真正使用那一刻。这种组合在企业级系统中特别适合处理高成本、低频次、条件性使用的组件，比如远程服务客户端、大配置对象、动态策略工厂等。
核心思路：用 Supplier 包装依赖，而非直接注入实例
传统构造函数注入是这样：
private final DatabaseService dbService;public OrderProcessor(DatabaseService dbService) { this.dbService = dbService; }
问题在于：只要 Spring 创建 OrderProcessor 实例，dbService 就必须已就绪（含连接池初始化、健康检查等）。而现实中，该处理器可能只在特定订单类型下才调用数据库。
改用 Supplier 后：
private final Supplierpublic OrderProcessor(Supplier
此时构造函数不触发任何初始化；dbService 实例仅在首次调用 dbServiceSupplier.get() 时才被创建和初始化。
实战四类典型场景
1. 延迟加载重资源服务
- 将远程调用客户端（如 FeignClient、gRPC stub）封装为 Supplier，避免启动时建立连接、预热缓存
- 示例：
Supplier<userprofileclient> clientSupplier = () -> new UserProfileClient(config);</userprofileclient>，注入后按需触发 - 配合 Spring 的
@Lazy注解可叠加效果，但 Supplier 提供更细粒度控制（例如仅对某个字段延迟）
2. 条件化策略实例化
- 不同业务线需要不同风控策略，但并非所有策略都会被用到
- 不写：
private final RiskStrategy highRiskStrategy = new HighRiskStrategy();（启动即加载） - 改写：
private final Supplier<riskstrategy> highRiskSupplier = () -> new HighRiskStrategy(rulesLoader);</riskstrategy> - 运行时根据订单金额判断是否调用
highRiskSupplier.get()，未命中则零开销
3. 构造函数注入 + Supplier 缓存复用
- 某些对象可复用但不宜全局单例（如带租户上下文的解析器）
- 用 Suppliers.memoize() 封装：确保同一 Supplier 实例只初始化一次
- 示例：
private final Supplier<tenantconfigparser> parserSupplier = Suppliers.memoize(() -> new TenantConfigParser(tenantId));</tenantconfigparser> - 多次调用
parserSupplier.get()返回同一实例，线程安全且无重复构造
4. 单元测试友好：轻松替换模拟行为
- 测试时无需启动完整容器，直接传入返回 Mock 对象的 Supplier
- 示例测试代码：
new OrderProcessor(() -> mock(DatabaseService.class)) - 比 @MockBean 更轻量，不依赖 Spring TestContext，适合纯 JUnit5 快速验证逻辑分支
与 Spring 容器协同的关键实践
Supplier 本身是普通函数式接口，Spring 不会自动识别其延迟语义，需主动配合：
- 声明 Bean 时显式返回 Supplier：在 @Configuration 类中定义
@Bean public Supplier<reportgenerator> reportSupplier() { return () -> new ReportGenerator(dataSource); }</reportgenerator> - 避免在 @PostConstruct 或构造函数中提前调用 .get()，否则失去延迟意义
- 若依赖本身由 Spring 管理（如 ReportGenerator 是 @Service），可用 ObjectProvider 或 ApplicationContext.getBeanProvider() 替代裸 Supplier，获得生命周期感知能力
- 注意线程安全：Supplier 实现若含状态（如缓存字段），需自行同步；推荐优先使用无状态 lambda 或 memoize 封装
不推荐滥用的边界
Supplier 延迟注入不是银弹：
- 高频调用的核心服务（如日志记录器、基础工具类）没必要包装，增加间接层反而影响性能
- 强依赖项（如数据库事务管理器）必须在构造完成时就可用，否则违反业务契约
- 多个 Supplier 在同一方法内连续 get()，不如一次性注入原始实例简洁
- 过度嵌套（如 Supplier
>）会显著降低可读性，应通过命名和提取方法改善
