Spring MVC 不支持在 @GetMapping 等请求处理方法的参数中直接注入自定义 Bean（如接口类型），仅允许特定上下文对象（如 HttpServletRequest、Model、@PathVariable 等）；真正的依赖注入必须通过构造器或字段完成。
spring mvc 不支持在 `@getmapping` 等请求处理方法的参数中直接注入自定义 bean（如接口类型），仅允许特定上下文对象（如 `httpservletrequest`、`model`、`@pathvariable` 等）；真正的依赖注入必须通过构造器或字段完成。
在 Spring MVC 中，控制器（@Controller）的请求处理方法（如 @GetMapping, @PostMapping）并非普通 Spring Bean 方法调用，而是由 DispatcherServlet 通过 HandlerAdapter（如 RequestMappingHandlerAdapter）统一调度执行的。该机制对方法参数有严格约定：它只支持预注册的 HandlerMethodArgumentResolver 所能解析的参数类型——例如：
- Servlet API 原生对象：HttpServletRequest, HttpServletResponse, HttpSession
- Spring MVC 内置抽象：Model, ModelMap, RedirectAttributes, @RequestParam, @RequestBody, @PathVariable
- 特定注解驱动对象：@Valid, @RequestHeader, @CookieValue 等
⚠️ 关键限制：普通业务 Bean（如 FooBarRepository 接口或其实现类）不在此列。当你写：
@GetMapping("/foobars")
public String getFooBars(FooBarRepository repository) { ... }
Spring 并不会从 ApplicationContext 中查找并注入已注册的 FooBarRepository Bean，而是试图将 FooBarRepository 当作一个需“按需实例化”的参数类型进行反射构造——这显然失败，因为接口无法实例化（报错 No primary or single unique constructor found for interface...），甚至若误写为实现类，也会因绕过 Spring 容器生命周期而丢失其依赖（如 @ConfigurationProperties 注入的 AppProperties 为 null）。
✅ 正确做法：将依赖声明在控制器构造器或字段中，交由 Spring 容器在 Bean 创建阶段完成完整依赖注入：
@Controller
public class FooBarController {
private final FooBarRepository fooBarRepository;
// ✅ 构造器注入 —— 推荐方式（不可变、可测试、显式依赖）
public FooBarController(FooBarRepository fooBarRepository) {
this.fooBarRepository = fooBarRepository;
}
@GetMapping("/foobars")
public String getFooBars(Model model) {
model.addAttribute("foobars", fooBarRepository.getFooBars());
return "foobars/list";
}
}
同时确保 DefaultFooBarRepository 正确注册为 FooBarRepository 类型的 Bean：
@Repository // 或 @Service，Spring 会自动将其注册为接口类型的 Bean
public class DefaultFooBarRepository implements FooBarRepository {
private final AppProperties appProperties; // ✅ 构造器注入 AppProperties
public DefaultFooBarRepository(AppProperties appProperties) {
this.appProperties = appProperties;
}
// ...
}
? 补充说明：
- @Repository("fooBarRepository") 中的 bean 名称仅用于显式引用（如 @Qualifier("fooBarRepository")），不影响类型匹配；Spring 默认按类型（FooBarRepository）自动装配，无需额外配置。
- Thymeleaf 视图中 ${@fooBarRepository.getFooBars()} 能正常工作，是因为 @beanName 语法是 Thymeleaf 的 SpEL 扩展，直接从 Spring ApplicationContext 中获取 Bean，与控制器方法参数解析机制完全无关。
- 若需在方法内动态获取 Bean（极少数场景），应通过 ApplicationContext（如实现 ApplicationContextAware），但违背控制反转原则，不推荐。
总结：控制器方法参数 ≠ 依赖注入入口，而是请求上下文适配层。坚持构造器注入业务依赖、方法参数专注请求数据绑定，既是 Spring MVC 的设计契约，也是构建健壮、可测 Web 层的最佳实践。
