Spring MVC 不支持在 @GetMapping 等请求处理方法中直接通过参数进行 Bean 接口注入；依赖注入仅在构造器、@Autowired 字段或 @Autowired setter 方法中由 IoC 容器完成，而处理器方法参数由 HandlerMethodArgumentResolver 体系解析，仅支持特定类型（如 HttpServletRequest、@PathVariable、@RequestBody 等）。
spring mvc 不支持在 `@getmapping` 等请求处理方法中直接通过参数进行 bean 接口注入；依赖注入仅在构造器、`@autowired` 字段或 `@autowired` setter 方法中由 ioc 容器完成，而处理器方法参数由 handlermethodargumentresolver 体系解析，仅支持特定类型（如 `httpservletrequest`、`@pathvariable`、`@requestbody` 等）。
在 Spring MVC 的请求处理生命周期中，控制器（Controller）本身是 Spring 管理的 Bean，其实例化与依赖注入发生在容器启动阶段——此时 Spring 会根据构造器、@Autowired 注解或 @Resource 等完成对 FooBarRepository 等服务接口的注入。但当请求到达时，DispatcherServlet 并不会为每个 HTTP 请求重新执行依赖注入；相反，它会调用已初始化好的 Controller 实例的 handler 方法（如 @GetMapping 标注的方法），并将该方法的参数交由 HandlerMethodArgumentResolver 链逐一解析。
关键点在于：handler 方法的参数不是由 Spring 的依赖注入容器（BeanFactory）提供，而是由 MVC 框架的参数解析机制动态构造的。该机制默认只识别以下几类参数：
- Servlet API 原生对象：HttpServletRequest、HttpServletResponse、HttpSession、Principal 等；
- Web 相关注解参数：@PathVariable、@RequestParam、@RequestBody、@RequestHeader、@CookieValue、@ModelAttribute 等；
- Errors / BindingResult（需紧跟 @ModelAttribute 后）；
- Model / ModelMap / RedirectAttributes 等 MVC 上下文对象；
- java.util.Locale、java.time.ZoneId 等可自动解析的上下文感知类型。
而像 FooBarRepository 这样的自定义业务接口，并不在 HandlerMethodArgumentResolver 的默认支持范围内。因此当你写：
@GetMapping("/foobars")
public String getFooBars(FooBarRepository repository) { ... }
Spring 实际上尝试“按类型创建一个 FooBarRepository 实例”（因为找不到匹配的 resolver），但由于它是接口，无法实例化，于是抛出：
IllegalStateException: No primary or single unique constructor found for interface ...
更令人困惑的是，当你改用实现类 DefaultFooBarRepository 作为参数时，错误变为构造器依赖 AppProperties 为 null ——这正印证了上述机制：Spring 此时试图反射调用 DefaultFooBarRepository 的构造器来新建一个实例（而非复用容器中已存在的 Bean），而该构造器所需 AppProperties 未被注入（因非容器管理的临时实例），导致空指针。
✅ 正确做法：将依赖声明在控制器的构造器（推荐）、字段或 setter 中：
@Controller
public class FooBarController {
private final FooBarRepository fooBarRepository;
// ✅ 构造器注入：Spring 在 Bean 初始化时完成依赖解析与注入
public FooBarController(FooBarRepository fooBarRepository) {
this.fooBarRepository = fooBarRepository;
}
@GetMapping("/foobars")
public String getFooBars(Model model) {
model.addAttribute("foobars", fooBarRepository.getFooBars());
return "foobars";
}
}
此方式具备以下优势：
- 符合不可变性与测试友好原则（依赖显式、final、无空状态）；
- 利用 Spring 的 AutowireCapableBeanFactory 自动按类型（FooBarRepository）匹配唯一 Bean（如 DefaultFooBarRepository）；
- 无需额外配置：只要 DefaultFooBarRepository 被 @Repository 或 @Service 标注且在组件扫描路径下，Spring 即自动注册为 FooBarRepository 类型的 Bean。
⚠️ 注意事项：
- 若存在多个 FooBarRepository 实现，需配合 @Primary 或 @Qualifier("beanName") 消除歧义；
- 不要试图在 handler 方法中注入任意 Service/Repository——这是设计误用，违背 MVC 分层职责；
- Thymeleaf 表达式 ${@fooBarRepository.getFooBars()} 能工作，是因为 @beanName 是 Spring 表达式语言（SpEL）语法，直接从 ApplicationContext 中获取 Bean，与 controller 方法参数解析完全无关。
总结：Spring MVC 的 handler 方法参数 ≠ Spring Bean 依赖注入入口。请始终将业务依赖注入到 Controller 实例层面（构造器优先），再于 handler 方法中通过成员变量使用——这才是符合框架设计哲学、稳定可靠且易于维护的实践方式。
