当Controller方法参数**带`@RequestParam

当Controller方法参数带@RequestParam和不带@RequestParam且为复杂类型时，Spring MVC的处理机制有显著差异，核心区别如下：

一、带@RequestParam的参数处理

1. 解析器

由RequestParamMethodArgumentResolver处理（无论参数类型是否为复杂类型）。

2. 核心逻辑

• 参数来源：从请求参数（QueryString/FormData）中提取，支持多个同名参数（如ids=1&ids=2）。
• 类型转换：通过ConversionService将字符串参数转换为目标类型：
  • 简单类型（Long、String等）直接转换。
  • 集合类型（List<Long>）会将多个参数值转为集合，并逐个转换元素类型。
  • 复杂对象（如自定义Bean）需有字符串构造函数或静态工厂方法（否则转换失败）。
• 参数匹配：可通过@RequestParam("name")指定请求参数名，不依赖参数变量名。
• 必传控制：默认required = true，缺少参数会报错；可设置required = false或defaultValue。

3. 适用场景

• 简单参数（如id、name）。
• 集合/数组参数（如List<Long> ids）。
• 需要显式控制参数名、必传性或默认值的场景。

二、不带@RequestParam且为复杂类型的参数处理

1. 解析器

由ModelAttributeMethodProcessor处理（复杂类型指非简单类型，如自定义Java Bean）。

2. 核心逻辑

• 实例化：通过反射调用类的无参构造函数创建对象（若没有无参构造函数则报错）。
• 数据绑定：使用WebDataBinder将请求参数映射到对象属性（支持嵌套属性，如user.address.city）。
• 参数匹配：默认通过参数变量名与请求参数名匹配（如User user匹配?name=xxx&age=xxx）。
• 扩展能力：支持通过@InitBinder自定义属性编辑器，处理复杂类型转换（如日期格式）。

3. 适用场景

• 自定义Java Bean（如User、Order）。
• 需要绑定多个相关参数到一个对象的场景（如表单提交）。

三、核心区别对比表

四、典型错误场景

1. 不带@RequestParam的List参数：
   List<Long> ids会因ModelAttributeMethodProcessor无法实例化List接口而报错。

2. 带@RequestParam的复杂对象：
   @RequestParam User user若User无字符串构造函数，会因转换失败报错（应改用无注解的复杂类型处理）。

3. 无无参构造函数的复杂类型：
   不带注解的User类若只有带参构造函数，会因无法实例化而报错。

总结

• 带@RequestParam：适用于简单参数、集合参数，强调显式控制参数行为。
• 不带@RequestParam（复杂类型）：适用于自定义Bean，强调自动属性绑定，依赖无参构造函数。

理解这两种机制的差异，能帮助避免参数绑定错误，选择合适的注解和参数类型。