Spring 5.2.3升级后控制器@RequestParam参数值出现重复问题咨询

• 多来源同名参数的默认拼接逻辑变更
  Spring 5.2.3 版本调整了RequestParamMethodArgumentResolver的参数取值规则：对于同一个请求中，从QueryString、Form表单体、自定义HttpServletRequestWrapper三个不同来源检测到的同名参数，框架不再执行后值覆盖前值的逻辑，而是直接将多来源的同名字段值以逗号为分隔符拼接为一个字符串。
  多数老项目升级前会自定义参数包装类（用于XSS过滤、参数解密、全局参数修改），这类自定义Wrapper通常会重写getParameter()、getParameterValues()方法。旧版本Spring会优先取Wrapper返回的参数值，不会重复读取原始请求的同名参数；升级到5.2.3后，框架会同时遍历原始请求和Wrapper中的同名参数，两个来源的相同值直接被拼接，就会出现“原取值,原取值”的表现。
• 请求链路重复触发参数解析
  POST表单场景下，Tomcat容器只有在第一次调用getParameter*系列方法时，才会从请求InputStream中解析表单参数并缓存到parameterMap中。如果链路中存在自定义Filter、拦截器在解析完参数后，将原始请求替换为新的ServletRequestWrapper且没有复用已缓存的parameterMap，会导致Tomcat第二次从请求流中解析表单参数，两次解析得到的同值参数被Spring框架拼接，最终出现所有参数重复的效果。
• 冲突的全局参数转换配置
  如果项目为String类型的请求参数配置了全局自定义Converter，未判断实际入参的数组长度，直接对单值参数执行了数组转字符串的重复拼接逻辑，也会触发该问题。这类场景的影响范围通常只覆盖特定参数类型，不会出现所有@RequestParam参数都重复的表现，排查优先级较低。

快速定位方法

• 在控制器方法第一行打印request.getParameter("appName")的原始返回值：如果该值已经是重复拼接的内容，说明问题出在Servlet容器层的参数解析环节，和SpringMVC的参数绑定逻辑无关；如果原始值正常，仅@RequestParam绑定的参数值重复，说明是Spring参数解析链路触发的拼接逻辑。
• 临时将Spring版本回退至5.2.2验证，如果问题消失，可直接确认是5.2.3版本的行为变更导致的兼容性问题。

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