spring 默认采用 singleton 作用域，适用于绝大多数无状态组件（如 controller、service、dao）；仅在明确需要隔离状态时，才选用 prototype、request、session 等作用域——这是提升性能、保障线程安全与简化生命周期管理的行业共识。
spring 默认采用 singleton 作用域，适用于绝大多数无状态组件（如 controller、service、dao）；仅在明确需要隔离状态时，才选用 prototype、request、session 等作用域——这是提升性能、保障线程安全与简化生命周期管理的行业共识。
在 Spring 应用开发中，Bean 的作用域（Scope）直接决定了其实例数量、生命周期边界及线程可见性，是架构设计的关键决策点。行业主流实践明确推荐：以 singleton 为默认和首选，仅在必要时才突破该约定。
✅ 推荐分层作用域设计（Web 应用典型结构）
| 层级 | 示例类 | 推荐作用域 | 理由 |
|---|---|---|---|
| Controller | TestController |
singleton（默认） |
无业务状态，仅协调请求流转；由 Spring MVC 每次请求注入新 @RequestBody 或 @RequestParam，自身无需持状态 |
| API/DTO 封装层 | TestAPI |
singleton（非必需 prototype） |
若仅作数据转换或轻量逻辑（如 UserDTO.toEntity()），应保持无状态；prototype 反而增加 GC 压力且无收益 |
| Service | TestService |
singleton（✅ 正确） |
如题所述“仅含工具方法”，完全符合无状态设计原则；共享实例可复用连接池、缓存等资源，性能最优 |
? 关键验证：若
TestAPI被声明为@Scope("prototype")，但实际未维护任何请求/会话级状态（如未使用ThreadLocal、未缓存用户上下文），则该配置属于过度设计——不仅浪费对象创建开销，还可能因开发者误以为“多例即安全”而忽视真正的线程风险。
⚠️ 何时必须切换作用域？——按场景精准选择
-
prototype：仅当 Bean 自身持有可变状态且需严格隔离（如购物车临时计算上下文、带内部计数器的批处理任务对象）。注意：Spring 不管理其销毁，需手动调用@PreDestroy或显式清理资源。@Component @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) // 显式声明更清晰 public class ShoppingCart { private final List<Item> items = new ArrayList<>(); // 状态字段 public void addItem(Item item) { items.add(item); } // 状态变更 } -
request/session：仅限 Web 环境，且必须基于WebApplicationContext。例如：-
@Scope("request")：封装当前 HTTP 请求的认证令牌、请求 ID（MDC上下文）； -
@Scope("session")：用户个性化偏好设置（避免重复查询数据库）。
-
-
application/websocket：全局共享配置（如系统开关）或长连接会话状态（如在线用户统计），使用频率极低。
? 绝对避免的误区
- ❌ 为
Controller或Service盲目设为prototype：违背 Spring 设计哲学，导致容器无法优化代理、AOP 增强失效，且@Transactional等注解可能行为异常； - ❌ 混淆“线程安全”与“作用域”：
singletonBean 非线程安全 ≠ 不能用于多线程——无状态即安全；若需状态，应通过request作用域或外部存储（Redis/DB）解耦，而非依赖 Bean 实例隔离； - ❌ 在非 Web 环境（如 Spring Boot CLI 应用）使用
request/session：将直接抛出IllegalStateException。
? 总结：作用域选型黄金法则
-
默认即正义：所有
@Component,@Service,@Repository,@Controller默认singleton，无需显式标注； - 状态驱动决策：仅当 Bean 自身必须持有且隔离状态 时，才考虑非单例作用域；
-
优先外部化状态：用户会话数据存
HttpSession/Redis，请求上下文用RequestContextHolder，比request作用域更灵活可控； - 性能与可测性并重：单例 Bean 更易单元测试（无状态）、更少内存占用、更高吞吐——这正是 Spring “约定优于配置”理念的核心体现。
遵循此指南，你的 TestController → TestAPI → TestService 结构中，全部采用 singleton 不仅正确，而且是最优解。
