执行 ServletInvocableHandlerMethod 的 invokeAndHandle 方法。整个方法包含了请求调用和响应处理，请求中包含了参数的解析过程。
2.猜想验证其实上面扯了这么多，还没说到关键点为什么重写了 WebMvcConfigurationSupport 会导致后台接收不了 FormData？按照之前的分析我们需要的 FormData 数据可能在哪个阶段丢了。前台传过来的数据肯定会存在 request 对象中，既然这样，笨办法是不是可以想比较下没有重写和重写的情景，看看两次的 request 对象是否有差异不就行了。
我们把断点打在 InvocableHandlerMethod#getMethodArgumentValues 方法中，因为这里是从 request 对象中提取出参数的方法。我们要做的只需观察两次的 request 对象的差异即可。
果不其然，重写过 WebMvcConfigurationSupport 后，少了 formParams 这个属性，而 formParams 包含了我们想要的参数 ids[]。
至于为什么重写 WebMvcConfigurationSupport 会丢失 formParams？是不是毫无头绪？别急，我们先看下这个 formParams 是什么。
从上图可以看得到 formParams 是 FormContentFilter 中静态内部类 FomContentRequestWrapper 的一个属性。猜想 formParams 应该是使用 FormContentFilter 过滤器从 request 对象提取出来的，那现在少了 formParams 应该是过滤器 FormContentFilter 没有加载。
重写配置类之前没有配置过 FormContentFilter 过滤器，所以这个过滤器应该是 SpringBoot 自动配置并加载的。来看下 SpringBoot 的 WebMvc 自动配置类 WebMvcAutoConfiguration。这个类配置在 spring.factories 里,SpringBoot 启动时自动加载配置在里面的类，是 SpringBoot 的扩展机制，类似 java 的 SPI。
FormContentFilter 如我们所料在 SpringBoot 的 WebMvc 自动配置类中，随着 SpringBoot 启动自动装配。那至于为什么重写了 WebMvcConfigurationSupport 就会导致自动配置失效了呢？再看下 WebMvcAutoConfiguration 的头部注解描述。
@ConditionalOnMissingBean({WebMvcConfigurationSupport.class})，意思就是 Spring 容器中没有 WebMvcConfigurationSupport 类相关 bean 自动配置才会生效。而我这里重写 WebMvcConfigurationSupport 并加载到 Spring 容器中，显然导致 SpringBoot 自动配置不能生效，最终表现出来的现象是后台接收不到前台 FromData 传值。
四、解决方案