前言
在 Spring 生态的长期演进中，控制反转（IoC）与依赖注入（DI）早已成为企业级开发的默认心智模型。然而，随着项目规模的膨胀，一种"万物皆 Bean"的教条主义倾向正在悄然侵蚀代码质量：容器启动时间从秒级劣化至分钟级，应用上下文中充斥着数千个仅被单一组件使用的伪单例，原本内聚的业务逻辑被过度抽象为散落的配置类。这种对框架的盲目崇拜，本质上是对面向对象设计原则的背离。
Spring 从未宣称要接管所有对象的生杀大权。相反，它提供了一套精密的分层治理体系：容器负责管理具有基础设施语义的协作组件，而开发者则保留对纯领域对象和工具对象的直接控制权。正确划分这条边界，不仅是性能优化的技术手段，更是区分"框架使用者"与"架构设计者"的认知分水岭。
一、 为什么不能"万物皆 Bean"
要理解何时不该使用依赖注入，首先必须量化"成为一个 Bean"的真实成本。这并非简单的 new 操作，而是一条涉及反射、代理、后处理的完整流水线。
当一个类被注册为 Bean 时，Spring 容器需要执行以下操作：通过 CGLIB 或 JDK 动态代理生成子类（若存在 AOP 需求），遍历所有 BeanPostProcessor 进行属性填充与方法拦截织入，解析并注入所有依赖项，执行初始化回调（@PostConstruct、InitializingBean），最后将实例放入单例缓存池。这一系列操作的耗时通常在毫秒级，对于单个 Bean 微不足道，但当数量累积至数千时，启动阶段的延迟将呈线性甚至超线性增长。
更隐蔽的成本在于内存占用。每个 Bean 实例除了自身字段外，还携带代理对象的元数据、AOP 拦截器链、依赖描述符等容器级附加结构。一个空的 Service Bean 经 CGLIB 代理后，其实际内存占用可达原始类的 3-5 倍。在高并发微服务场景中，这些本可避免的内存开销会直接转化为 GC 压力与响应延迟。
从 JVM 运行时角度看，直接 new 的对象享有 JIT 编译器的特殊优待。HotSpot VM 的逃逸分析（Escape Analysis）能够识别出未逃逸出方法作用域的对象，将其分配在栈上而非堆中，配合标量替换（Scalar Replacement）进一步消除对象头开销。这意味着许多临时对象的创建在机器码层面被完全优化掉，实现了真正的零成本抽象。而经由容器获取的 Bean，由于引用关系复杂且跨越多个调用帧，逃逸分析几乎无法生效，每次访问都必须经过堆内存寻址与可能的缓存未命中。
因此，"是否纳入容器"不是一个风格偏好问题，而是一个有明确物理代价的工程权衡。只有当容器提供的价值（生命周期管理、横切增强、依赖解析）显著超过其运行时成本时，注入才是合理的选择。
二、 适合直接实例化的五大场景
基于上述成本分析，以下五类场景因其本质特征与容器能力不匹配，应当坚决采用直接实例化。每个场景均附带生产级代码示例与设计意图解析。
1. 无状态纯工具类：线程安全与零开销的统一
此类对象不包含任何可变状态，所有方法均为基于入参的纯函数计算。它们是数学意义上的"函数"，而非面向对象意义上的"对象"。
java
@Component
@RequiredArgsConstructor
public class PathRoutingService {
// ✅ 正确：无状态工具类，直接 new 复用
// AntPathMatcher 是线程安全的，match() 方法不修改任何内部状态
private final AntPathMatcher pathMatcher = new AntPathMatcher();
// ❌ 错误示范（注释说明）：
// @Autowired private AntPathMatcher pathMatcher;
// 容器注入不会带来任何额外能力，反而增加启动开销与内存占用
public boolean isWhitelisted(String requestPath, List<String> patterns) {
for (String pattern : patterns) {
if (pathMatcher.match(pattern, requestPath)) {
return true;
}
}
return false;
}
}设计原理 ：AntPathMatcher 的 match() 方法内部仅读取构造时传入的配置参数，不写入任何实例字段。这种不可变性使其天然线程安全，可在任意数量的线程间共享同一实例而无需同步。将其注册为 Bean 的唯一"好处"是可以被其他组件注入，但路径匹配通常是路由层的私有逻辑，暴露为全局 Bean 违反了最小知识原则。直接 new 既保证了线程安全，又避免了容器开销，还通过字段声明清晰表达了"这是一个内部工具"的设计意图。
关键验证点 ：使用前必须查阅源码或官方文档确认线程安全性。SimpleDateFormat 常被误认为工具类，但其内部持有可变 Calendar 实例，绝非线程安全，绝不能作为共享字段直接 new。
2. 轻量级策略对象：封装私有算法细节
当对象代表一种由配置驱动的算法规则，且仅服务于单一宿主 Bean 时，它是宿主的"私有实现"，而非独立的"协作组件"。
java
@Service
@RequiredArgsConstructor
public class OrderPricingService {
// ✅ 正确：策略对象由宿主构造，参数来自外部配置
// DiscountStrategy 是 PricingService 的私有算法细节
private final DiscountCalculator discountCalculator;
public OrderPricingService(
@Value("${pricing.discount.rate:0.1}") double discountRate,
@Value("${pricing.discount.max-cap:100}") double maxCap) {
// 策略对象在构造期组装，运行时不再变化
this.discountCalculator = new DiscountCalculator(discountRate, maxCap);
}
public BigDecimal calculateFinalPrice(Order order) {
BigDecimal basePrice = order.getBasePrice();
// 策略对象的使用完全内聚于当前 Service
return discountCalculator.apply(basePrice);
}
// 策略类定义为静态内部类或包级私有类，强调其附属地位
static class DiscountCalculator {
private final double rate;
private final double maxCap;
DiscountCalculator(double rate, double maxCap) {
this.rate = rate;
this.maxCap = maxCap;
}
BigDecimal apply(BigDecimal price) {
double discount = Math.min(price.doubleValue() * rate, maxCap);
return price.subtract(BigDecimal.valueOf(discount));
}
}
}设计原理 ：DiscountCalculator 的行为完全由构造参数决定，不依赖任何 Spring 基础设施。若将其抽取为独立 Bean 并通过 @Autowired 注入，会产生三重损害：其一，阅读 OrderPricingService 时必须跳转至另一个文件才能理解定价逻辑，破坏了代码的局部可读性；其二，DiscountCalculator 被暴露为全局 Bean，其他无关 Service 可能误注入并滥用，违反了封装原则；其三，若未来需要支持多套定价策略（如按租户区分），Bean 方式需要引入 @Qualifier 或条件装配等复杂机制，而直接 new 只需在构造器中增加一个分支判断。
核心收益：将策略对象视为"带参数的纯函数"而非"有状态的组件"，使业务逻辑的表达回归到算法本身，而非框架的装配规则。
3. 短生命周期临时对象：规避 Prototype 的性能陷阱
此类对象持有可变状态，仅在单次请求或方法调用内有效，用完即弃。它们是高并发热点路径上的常见角色。
java
@Service
public class LogAggregationService {
public String aggregateLogs(List<LogEntry> entries) {
// ✅ 正确：StringBuilder 是典型的短命可变对象
// 直接 new 享受 JIT 栈上分配优化，GC 压力趋近于零
StringBuilder buffer = new StringBuilder(entries.size() * 128);
for (LogEntry entry : entries) {
buffer.append(entry.getTimestamp())
.append(" | ")
.append(entry.getLevel())
.append(" | ")
.append(entry.getMessage())
.append('\n');
}
return buffer.toString();
// ❌ 错误示范（概念说明）：
// @Autowired ObjectProvider<StringBuilder> builderProvider;
// StringBuilder sb = builderProvider.getObject();
// Prototype Bean 仍需经过容器查找、实例化、后处理流程
// 在高 QPS 场景下，容器开销远超对象创建本身
}
}设计原理 ：Prototype 作用域常被误解为"短命对象的解决方案"，实则它是一个性能反模式。每次 getObject() 调用都会触发完整的 Bean 创建流水线，包括同步锁竞争（单例注册表的并发保护）、后处理器遍历、属性类型转换等。在日志聚合这类每秒执行数万次的热点方法中，容器开销将成为主导因素。直接 new 的 StringBuilder 经 HotSpot 逃逸分析后，大概率被分配在执行线程的栈帧上，方法返回时随栈帧弹出自动回收，完全不触及垃圾收集器。
扩展场景 ：JSON 序列化器（如 new JsonWriter(outputStream)）、XML 解析器、加密 Cipher 实例、数据库 ResultSet 处理器等均属此类。核心判断标准是"可变状态 + 高频创建"，两者同时满足即排除容器管理。
4. 第三方库的非 Spring 原生对象：保持依赖关系的内聚性
当第三方库不提供 Spring Boot Starter，或其构造函数需要复杂参数，且仅被单一组件使用时，强行 @Bean 包装是一种不必要的间接层。
java
@Service
public class ExternalNotificationService {
// ✅ 正确：第三方客户端作为私有依赖，在使用处直接构建
// 明确表达"这个客户端就是为通知服务准备的"
private final NotificationClient client;
public ExternalNotificationService(
@Value("${notification.endpoint}") String endpoint,
@Value("${notification.api-key}") String apiKey,
@Value("${notification.timeout-ms:5000}") int timeoutMs) {
// 构造参数全部来自 Spring 配置，但客户端本身不是 Bean
this.client = NotificationClient.builder()
.endpoint(endpoint)
.apiKey(apiKey)
.timeout(Duration.ofMillis(timeoutMs))
.retryPolicy(RetryPolicy.exponentialBackoff(3))
.build();
}
public void sendAlert(String message) {
client.send(NotificationRequest.of(message));
}
// ❌ 对比：若在 @Configuration 中定义 @Bean
// 1. 产生一个仅被 ExternalNotificationService 消费的全局 Bean
// 2. 配置类与使用方分离，修改时需跨文件协调
// 3. 若未来需要第二个不同配置的客户端，需引入 @Qualifier 等复杂机制
}设计原理 ：@Configuration 类的职责是声明"基础设施"，即那些具有独立生命周期、需要被多个消费者共享的资源（如数据源、连接池、消息模板）。而 NotificationClient 在此场景中是 ExternalNotificationService 的专属依赖，其配置参数、生命周期、错误处理策略均与宿主紧密耦合。将其提升为全局 Bean，等于将一个"实现细节"伪装成了"基础设施"，误导后续维护者认为它可以被安全地注入到其他组件中。
例外情况 ：若客户端的创建涉及昂贵资源（如 TCP 连接池建立、TLS 握手），即使只有一个消费者，也应使用 @Bean 管理，以便利用容器的懒加载（@Lazy）和销毁回调（@PreDestroy）确保资源的正确释放。此时权衡的天平从"内聚性"转向了"资源安全"。
5. 测试替身与手动组装：脱离容器的确定性验证
在单元测试中，直接 new 是保证测试隔离性与执行速度的基石。
java
@ExtendWith(MockitoExtension.class)
class OrderPricingServiceTest {
@Test
void shouldApplyDiscountCorrectly() {
// ✅ 正确：直接构造被测对象，精确控制所有依赖
// 测试不依赖 Spring 上下文，执行时间 < 1ms
var calculator = new OrderPricingService.DiscountCalculator(0.1, 100);
var service = new OrderPricingService(calculator); // 假设构造器接受策略对象
Order order = Order.builder().basePrice(new BigDecimal("500")).build();
BigDecimal result = service.calculateFinalPrice(order);
assertEquals(new BigDecimal("450.00"), result);
}
// ❌ 对比：@SpringBootTest + @Autowired
// 1. 启动完整容器，耗时数秒至数十秒
// 2. 加载大量无关 Bean，测试结果受环境污染
// 3. 无法精确控制 DiscountCalculator 的参数，难以覆盖边界条件
}设计原理 ：单元测试的核心价值在于"快速反馈"与"行为隔离"。Spring 上下文是一个庞大的全局状态机，其中任何一个 Bean 的初始化失败、配置缺失或副作用都可能干扰目标测试。直接 new 确保了测试的可重复性与确定性，使开发者能够在编码过程中高频运行测试而不感知延迟。这也是为什么前述四种场景推荐直接 new 的深层原因之一：可测试性是设计质量的试金石，如果一个类必须依赖容器才能被构造，那它很可能承担了过多职责。
三、 绝对禁止手动 new 的红线区域
以下场景若使用 new，将导致功能性缺陷且无编译期提示，是必须严守的工程红线。
含有 Spring 注解的类 ：@Value、@Autowired、@Resource、@PostConstruct 等注解是容器后处理的契约，而非 Java 语言特性。手动 new 将使所有注解静默失效，字段值为 null，初始化方法不被调用。这是生产环境中最常见的隐蔽 Bug 来源。
实现 Spring 回调接口的类 ：InitializingBean、ApplicationContextAware、DisposableBean 等接口的回调由容器在特定生命周期节点触发。脱离容器即失去意义，对象将无法完成必要的初始化或资源清理。
需要 AOP 增强的 Service/Repository ：@Transactional、@Cacheable、@Async、@PreAuthorize 等注解依赖代理对象织入横切逻辑。new 出来的原始实例调用这些方法时，事务不会开启、缓存不会生效、权限不会校验，且无任何警告日志。数据一致性事故往往由此引发。
@Configuration 类本身 ：配置类必须被容器管理，否则其中的 @Bean 方法不会被扫描执行，整个配置模块静默失效。
四、 这样设计的深层收益
理解"何时 new、何时注入"不仅是为了遵守规范，更是为了获得以下四个维度的实质性收益。
性能收益的可量化性 ：减少不必要的 Bean 注册可直接缩短应用启动时间。在一个拥有 2000+ Bean 的典型微服务中，将其中 30% 的工具类、策略对象、临时对象改为直接 new，通常可将启动时间缩短 15%-25%，堆内存基线降低 10%-20%。在 Serverless 或弹性伸缩场景中，这意味着更快的冷启动速度与更低的资源账单。
认知负荷的结构性降低：代码的可读性不仅取决于命名与注释，更取决于信息的空间局部性。当策略对象、工具类以内联方式存在于使用处时，开发者无需在多个文件间跳转即可理解完整逻辑。这种"自包含"的代码结构显著降低了新成员的上手成本与日常维护的认知负担。
可测试性的内生保障 ：直接 new 的对象天然是可测试的，因为它们不依赖容器环境。这倒逼开发者在设计阶段就考虑构造函数的纯净性，避免隐式依赖。长此以往，代码库的整体可测试性将从"需要刻意维护的属性"变为"设计自然的副产品"。
架构演进的灵活性 ：当对象不被容器绑定时，重构的自由度大幅提升。可以将一个直接 new 的策略对象轻松迁移到非 Spring 环境（如批处理脚本、CLI 工具、Flink 作业），而无需剥离注解或模拟容器上下文。这种"框架无关性"是抵御技术栈锁定风险的重要屏障。
五、 决策矩阵
| 评估维度 | 选择依赖注入（@Autowired / @Bean） | 选择直接实例化（new） |
|---|---|---|
| 外部资源依赖 | 需要 DB/MQ/Cache/HTTP/配置中心 | 纯内存计算，无外部 IO |
| AOP 代理需求 | 需要事务/缓存/异步/权限/监控 | 无需横切增强，纯业务逻辑 |
| 组件共享范围 | 被 ≥2 个独立 Bean 引用 | 仅服务于单一宿主 Bean |
| 对象生命周期 | 与应用同生命周期，或需容器管理销毁 | 方法级/请求级，用完即弃 |
| 可变状态 | 有状态但由容器保证线程安全（如单例 Service） | 无状态，或有状态但绝不跨线程共享 |
| Spring 注解/回调 | 含有 @Value/@Autowired/@PostConstruct 等 | 无任何 Spring 注解，纯 POJO |
| 第三方库集成 | 提供 Starter，或需全局共享连接池 | 无 Starter，且为单一组件专属 |
| 典型代表 | DataSource, RedisTemplate, UserService, ConfigProperties | AntPathMatcher, Pattern, StringBuilder, RateLimiter, 私有策略类 |
| 性能特征 | 启动期一次性成本，运行时代理开销 | 零启动成本，JIT 可深度优化 |
| 可测试性 | 需 @SpringBootTest 或 MockBean | 直接构造，毫秒级执行 |
终极判断口诀：有状态、需代理、要共享、赖设施 → 注入；纯计算、私有化、短命、非原生 → new。