Spring Boot同端点按Content-Type区分POST请求映射歧义问题咨询

Spring MVC原生@PostMapping的consumes属性默认不支持基于Content-Type的自定义参数做路由区分，你遇到的启动歧义映射异常就是这个机制导致的，也不需要在单个方法里写大段switch/case硬编码分支。

Spring做路由初始化匹配时，对consumes声明的媒体类型只会校验「主类型/子类型」，不会解析媒体类型后面附带的自定义键值参数：
你代码里写的application/json;data-model=1和application/json;data-model=2，框架识别到的有效匹配条件都是「接收application/json类型的POST请求」，两个接口的路由判定条件完全重合，启动时就会直接抛出歧义映射错误。
这个逻辑和params属性的精确键值匹配逻辑不一样，params原生支持对请求参数做键值对精确匹配、以此区分同路径接口。

不需要硬写分支判断，根据你的项目复杂度选下面任意一种方案即可：

• 方案1：采用标准自定义媒体类型（零框架改造）
  把你现在带参数的Content-Type改成REST领域通用的自定义vendor媒体类型格式，比如application/vnd.yourdomain.cqrs-model-v1+json、application/vnd.yourdomain.cqrs-model-v2+json，这种格式的媒体类型主/子类型本身就有区分度，Spring原生的consumes匹配可以直接识别，不需要修改任何框架逻辑，也是CQRS风格REST API区分不同命令载荷的通用实践。
• 方案2：扩展RequestMappingHandlerMapping（保留现有写法）
  如果你一定要用application/json;data-model=x的格式，可以自定义请求映射处理器，重写媒体类型匹配逻辑，在原有主/子类型匹配的基础上，增加对Content-Type附带参数的精确比对，把mediaType的参数也纳入路由判定条件，就能直接复用你现在写的接口注解形式，不需要调整业务代码结构。
• 方案3：自定义模型版本注解+拦截器转发（轻量实现）
  自定义一个类似@DataModel(1)、@DataModel(2)的注解标注在不同处理方法上，在请求拦截阶段提前解析请求头Content-Type里的data-model值，把请求转发到对应标注了匹配版本的方法即可，这个方案不需要改动Spring MVC核心映射逻辑，实现成本最低。

注意：不要在单方法内堆switch分支做逻辑判断，随着后续CQRS命令类型增多，代码可维护性会快速下降，也违背了CQRS模式下命令与处理逻辑独立解耦的设计原则。

内容的提问来源于stack exchange，提问作者jjakubowski