在基于泛型抽象控制器（如 Controller）的架构中，若需为特定子类（如 ItemController）定制 @GetMapping 方法并添加 @RequestParam 参数，直接重写会导致重复映射冲突；正确做法是利用 @GetMapping(params = {...}) 指定请求参数约束，使父子方法共存且路由精准分流。
在基于泛型抽象控制器（如 `controller
在 Spring Boot 的 RESTful 控制器设计中，采用泛型抽象基类（如 Controller
✅ 正确解法：利用 @GetMapping.params 属性实现“条件化映射”
Spring 的 @RequestMapping 及其派生注解（如 @GetMapping）支持 params 属性，用于限定该方法仅在请求携带指定参数时才被匹配。这使得父子方法可共存于同一控制器中，形成「默认行为」与「增强行为」的优雅协同：
@RestController
@RequestMapping("/api/items")
public class ItemController extends Controller<item long itembrowseresponse itemshowresponse itemrequest itemrepository itemservice> {
public ItemController(ItemService service) {
super(service);
}
// ✅ 新增：仅当请求包含 ?page=xxx 时触发，返回分页结果
@GetMapping(params = "page")
@ResponseStatus(HttpStatus.OK)
public List<itembrowseresponse> index(@RequestParam(defaultValue = "0") Integer page) {
return service.index(page); // 调用支持分页的业务方法
}
// ✅ 父类原有方法仍有效：无 page 参数时，走默认全量查询
// GET /api/items → 调用父类 index()，返回全部数据
// GET /api/items?page=2 → 调用本方法，返回第2页数据
}</itembrowseresponse></item>
? 原理说明：
- @GetMapping 默认等价于 @GetMapping(params = {})，即匹配所有不带限制的 GET 请求；
- @GetMapping(params = "page") 表示 仅当请求 URL 包含 page 查询参数（无论值为何）时才匹配；
- Spring MVC 的 RequestMappingHandlerMapping 会按 params 条件进行精确路由，二者互不干扰，无冲突风险。
⚠️ 注意事项：
- ❌ 不要使用 @Deprecated + @Override 方式试图“屏蔽”父方法——Spring 仍会注册该映射；
- ❌ 避免 @GetMapping(value = "", params = "!page") 这类否定逻辑，语义不清且易出错；
- ✅ 若需更复杂条件（如多参数组合），可用数组形式：params = {"page", "size"}（要求同时存在）或 params = {"page != 0"}（支持 SpEL 表达式）；
- ✅ 推荐为分页场景统一使用 Pageable 参数（配合 @SpringQueryMap 或 Spring Data Web 支持），进一步简化：
@GetMapping(params = "page") public Page<itembrowseresponse> index(Pageable pageable) { return service.index(pageable); }</itembrowseresponse>
? 总结：
Spring 的 params 属性是解决泛型控制器定制化映射冲突的轻量级、声明式方案。它不破坏继承结构，不增加运行时开销，且完全符合 REST 设计原则——同一资源路径（/api/items）通过不同查询参数表达不同语义（全量 vs 分页）。掌握此技巧，即可在保持架构简洁性的同时，灵活应对真实业务中的差异化需求。
