springboot项目中后端接口不能处理content-type为multipart/form-data类型数据

1.问题现象

   项目中的一类接口（请求类型为POST，且参数接收未用实体封装属性，单参数映射，前段传参content-type采用multipart/form-data)突然无法映射到前台传入的值了，但是本地swagger调用正常调用，并且将本地服务注册到sit的eureka上，路由到本地的请求都能正常接受到前段传参，只有部署在sit环境的服务器处理无法正常处理。

2.问题分析

本地启动的服务时springboot内嵌tomcat服务器启动的，而部署在环境中的web服务容器时jboss，个人猜想和服务器容器的差异有关系，判断可能jboss容器所在的服务器可能出问题了；然而当测试将环境中的代码版本回滚到上个版本时，上述无法处理前段传参的接口恢复正常，可以正确处理前段传参。到此可以基本断定和本次代码变动有关了，于是拉取git提交记录，排查可能引起该问题的变动，发现同事在做 热部署上传功能的时候，因为原有的配置和自己新的功能实现有冲突，就将spring配置文件中的commonMultipartResolver的bean注入实例给注释了，于是赶紧放开注释，问题解决；

3.问题原因

问题解决了之后，思考了一下，阻止自己定位的核心问题还没有理清，为什么本地服务没有受到影响，而环境中的服务就除了问题了呢？自己决定看下源码：

从MultipartAutoConfiguration中可以看出，默认的multipartResolver解析器bean是依赖于servlet容器的，并且在没有MultipartResolver类的情况下注入StandardServletMultipartResolver的实例用来解析处理multipart有关的请求，这也就解释了为eureka路由到本地服务时本地可以正常处理，因为虽然配置文件中的解析器被注释了，但是servlet容器环境下，springboot自动注入了标准的multipart解析器；然而jboss中没有servlet相关jar包，无法启用multipart的自动配置，自然也就没有解析器去处理，需要手动注入。

4.个人感悟

在一个团队中，如果自己对某一项不是特别了解，不要擅自去删除可能你暂时无法理解的代码。如果实在要改动，最好拉上同事，相互评审评估一下，降低引入缺陷的风险，而且在出问题时，同事在帮忙定位时有明确的思路，更快的解决问题