Spring MVC 不支持在 @GetMapping 等请求处理方法中直接通过参数注入任意 Spring Bean（如接口类型），仅允许特定上下文对象（如 HttpServletRequest、Model、@PathVariable 等）；完整依赖注入必须通过构造器或字段完成。
spring mvc 不支持在 `@getmapping` 等请求处理方法中直接通过参数注入任意 spring bean（如接口类型），仅允许特定上下文对象（如 `httpservletrequest`、`model`、`@pathvariable` 等）；完整依赖注入必须通过构造器或字段完成。
在 Spring MVC 应用中，控制器（@Controller）的方法签名看似灵活，实则对参数类型有严格约定。当你尝试在 @GetMapping 方法中直接声明一个自定义接口作为参数：
@GetMapping("/foobars")
public String getFooBars(FooBarRepository repository) { // ❌ 错误：Spring 无法解析此参数
// ...
}
Spring 并不会去容器中查找类型为 FooBarRepository 的单例 Bean 并注入，而是将其视为需由 HandlerMethodArgumentResolver 解析的“请求上下文参数”。由于 FooBarRepository 不属于 Spring 预设的可解析参数类型（如 @RequestParam、@RequestBody、Model、HttpServletResponse 等），框架会抛出异常：
java.lang.IllegalStateException: No primary or single unique constructor found for interface FooBarRepository
该错误本质是 Spring 尝试将 FooBarRepository 当作一个需要反射实例化的“目标对象”来处理（例如用于数据绑定），而非从 IoC 容器中获取已有 Bean —— 这正是混淆的根源。
✅ 正确做法：将依赖注入移至构造器（推荐）或字段
Spring 在控制器实例化阶段（即 DispatcherServlet 初始化时）会执行完整的依赖注入，此时所有 @Bean、@Service、@Repository 等标注的组件均已注册并可按类型/名称解析。因此，应始终通过构造器注入业务依赖：
@Controller
public class FooBarController {
private final FooBarRepository fooBarRepository;
// ✅ 构造器注入：Spring 自动匹配 FooBarRepository 类型的 Bean（如 DefaultFooBarRepository）
public FooBarController(FooBarRepository fooBarRepository) {
this.fooBarRepository = fooBarRepository;
}
@GetMapping("/foobars")
public String getFooBars(Model model) { // ✅ 仅保留合法的 MVC 上下文参数
model.addAttribute("foobars", fooBarRepository.getFooBars());
return "foobars/list";
}
}
? 提示：FooBarRepository 接口无需额外配置即可被自动识别——只要存在且仅有一个实现类（如 @Repository("fooBarRepository") DefaultFooBarRepository），Spring 就能基于类型完成注入。若存在多个实现，可通过 @Qualifier("fooBarRepository") 显式指定。
⚠️ 补充说明：为何 Thymeleaf 视图中 @fooBarRepository 可用？
Thymeleaf 模板引擎通过 SpringTemplateEngine 集成 Spring 上下文，其表达式 @fooBarRepository 实际调用的是 ApplicationContext.getBean("fooBarRepository")，属于运行时动态查 Bean，不依赖方法参数解析机制。而控制器方法参数解析由 HandlerMethodArgumentResolver 链驱动，二者底层机制完全不同。
? 总结关键原则：
- ✅ 构造器注入是首选：保证不可变性、线程安全、测试友好，并完全兼容 Spring 的依赖注入容器；
- ❌ 禁止在 handler 方法参数中注入业务 Bean：仅限 Spring MVC 官方支持的上下文参数类型；
- ? 若需在方法内访问 Bean，可通过 ApplicationContext 手动获取（不推荐，破坏松耦合），或封装为 @Service 层方法调用；
- ? 扩展能力：如确需自定义参数解析逻辑（极少数场景），可实现 HandlerMethodArgumentResolver 并注册到 WebMvcConfigurer#addArgumentResolvers，但不应替代标准依赖注入。
遵循这一模式，既能充分利用 Spring 的 IoC 能力，又能保持控制器职责清晰、可测性强、符合 MVC 分层规范。
