Spring MVC九大组件之HandlerAdapter如何匹配规则进行消息转换

Spring MVC其实是内置了非常多的转换器来处理各种各样的MediaType。绝大多数情况下我们并不需要自己去定义转换器，全都交给Spring MVC去处理就够了。

但是Spring MVC既然帮我们内置了这么多的转换器，它默认都给我们加载进去了哪些了？若不是全部都加载进去，那我们遇到特殊的需求怎么自己往里放呢？

另外，我们一个请求request进来，Spring MVC到底是运用了怎么样的匹配规则，匹配到一个最适合的转换器进行消息转换的呢？

HTTP MediaType的基本知识

配上一张经典的Http请求详情图，方便下面的讲解

第一点

从上图可以看出Response的Content-Type为text/html，但是我们需要明白的是：决定Response的Content-Type的第一要素是Request请求头中的Accept属性的值，它也被称为MediaType。

这个Accept的值传给服务端，如果服务端支持这种MediaType，那么服务端就按照这个MediaType来返回对应的格式给Response，同时会把返回的的Content-Type设置成对应格式的MediaType。

若服务端明确不支持请求头中Accept指定的任何值时，那么就应该返回Http状态码：406 Not Acceptable。

比如上面截图例子：请求头中Accept支持多种MediaType，服务端最终返回的Content-Type为text/html显然是没有问题的。

第二点

如果Accept指定了多个MediaType，并且服务端也支持多个MediaType，那么Accept应该同时指定各个MediaType的QualityValue（也就是如图中的q值），服务端根据q值的大小来决定这几个MediaType类型的优先级，一般是大的优先。q值不指定时，默认视为q=1。

上图的Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3为Chrome浏览器的默认请求头的值。
它的含义为：服务端在支持的情况下应该优先返回text/html，其次是application/xhtml+xml。前面几个都不支持时，服务器可以自行处理 /，返回一种服务器自己支持的格式。

第三点

一个HTTP请求没有指定Accept，默认视为指定 Accept: /；请求头里没有指定Content-Type，默认视为 null，就是没有。

第四点

Content-Type若指定了，必须是具体确定的类型，不能包含 *。

备注：上面属于Http规范的范畴，Spring MVC基本遵循上面这几点~~~

Spring MVC默认加载的消息转换器有哪些

为了更好的理解Spring MVC对消息转换器的匹配规则，先弄清楚Spring MVC默认给我们加载了哪些HttpMessageConverter呢？

首先我们从现象上直观的看一下（因为消息转换器都放在了RequestMappingHandlerAdapter里，所以我们只需要关注运行时它里面的这个属性值即可）：

开启了@EnableWebMvc： 一共会有8个，只要我们classpath下有jackson的包，就会加载它进来。

看代码（因为开启了@EnableWebMvc，所以看WebMvcConfigurationSupport）：

public class WebMvcConfigurationSupport implements ApplicationContextAware, ServletContextAware {
	...
    protected final List<HttpMessageConverter<?>> getMessageConverters() {
    	if (this.messageConverters == null) {
    		this.messageConverters = new ArrayList<>();
    		// 调用者自己配置消息转换器
    		// 若调用者自己没有配置，那就走系统默认的转换器们~~~~~
    		configureMessageConverters(this.messageConverters);
    		if (this.messageConverters.isEmpty()) {
    			addDefaultHttpMessageConverters(this.messageConverters);
    		}
    
    		// 不管调用者配不配置，通过扩展接口进来的转换器都会添加进来
    		// 因为复写此个protected方法也是我们最为常用的自定义消息转换器的一个手段~~~~~
    		extendMessageConverters(this.messageConverters);
    	}
    	return this.messageConverters;
    }
    ...
    	
    // 大多数情况下，我们并不需要配置。因此看看系统默认的addDefaultHttpMessageConverters(this.messageConverters);
    protected final void addDefaultHttpMessageConverters(List<HttpMessageConverter<?>> messageConverters) {
    	StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
    	stringHttpMessageConverter.setWriteAcceptCharset(false);  // see SPR-7316

    	messageConverters.add(new ByteArrayHttpMessageConverter());
    	messageConverters.add(stringHttpMessageConverter);
    	messageConverters.add(new ResourceHttpMessageConverter());
    	messageConverters.add(new ResourceRegionHttpMessageConverter());


    	try {
    		messageConverters.add(new SourceHttpMessageConverter<>());
    	}
    	catch (Throwable ex) {
    		// Ignore when no TransformerFactory implementation is available...
    	}
    	messageConverters.add(new AllEncompassingFormHttpMessageConverter());

    	if (romePresent) {
    		messageConverters.add(new AtomFeedHttpMessageConverter());
    		messageConverters.add(new RssChannelHttpMessageConverter());
    	}

    	if (jackson2XmlPresent) {
    		Jackson2ObjectMapperBuilder builder = Jackson2ObjectMapperBuilder.xml();
    		if (this.applicationContext != null) {
    			builder.applicationContext(this.applicationContext);
    		}
    		messageConverters.add(new MappingJackson2XmlHttpMessageConverter(builder.build()));
    	}
    	else if (jaxb2Present) {
    		messageConverters.add(new Jaxb2RootElementHttpMessageConverter());
    	}

    	if (jackson2Present) {
    		Jackson2ObjectMapperBuilder builder = Jackson2ObjectMapperBuilder.json();
    		if (this.applicationContext != null) {
    			builder.applicationContext(this.applicationContext);
    		}
    		messageConverters.add(new MappingJackson2HttpMessageConverter(builder.build()));
    	}
    	else if (gsonPresent) {
    		messageConverters.add(new GsonHttpMessageConverter());
    	}
    	else if (jsonbPresent) {
    		messageConverters.add(new JsonbHttpMessageConverter());
    	}

    	if (jackson2SmilePresent) {
    		Jackson2ObjectMapperBuilder builder = Jackson2ObjectMapperBuilder.smile();
    		if (this.applicationContext != null) {
    			builder.applicationContext(this.applicationContext);
    		}
    		messageConverters.add(new MappingJackson2SmileHttpMessageConverter(builder.build()));
    	}
    	if (jackson2CborPresent) {
    		Jackson2ObjectMapperBuilder builder = Jackson2ObjectMapperBuilder.cbor();
    		if (this.applicationContext != null) {
    			builder.applicationContext(this.applicationContext);
    		}
    		messageConverters.add(new MappingJackson2CborHttpMessageConverter(builder.build()));
    	}
    }
}

这个逻辑走下来，最终能被添加进去就是我们截图的那8个（当然这里指的我们只导入jackson处理json的这个jar的情况下~~~）

jackson2SmilePresent用于处理application/x-jackson-smile，代表类为：com.fasterxml.jackson.dataformat.smile.SmileFactory

jackson2CborPresent用于处理application/cbor，代表类为com.fasterxml.jackson.dataformat.cbor.CBORFactory

（Smile和CBOR就是一种数据格式，只是jackson强大的都给与了支持）当下绝大多数情况下我们只需要处理Json数据，所以只需要导入如下一个包即可：

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.9.8</version>
</dependency>

非常不建议导入jackson-all做这种全量导入，太重~

没有开启@EnableWebMvc，情况就不一样了：

我们发现仅仅只有4个，并且它并没有处理返回为Json的数据转换器。因此假如我们有如下两个Handler：

// 返回值为string类型
@ResponseBody
@RequestMapping(value = "/hello", method = RequestMethod.GET)
public String helloGet() throws Exception {
    // 请注意：我这里又有中文  又有英文
    return "哈喽，world";
}

// 返回值是个对象，希望被转换为
@ResponseBody
@RequestMapping(value = "/hello/json", method = RequestMethod.GET)
public Parent helloGetJson() throws Exception {
    return new Parent("fsx", 18);
}

浏览器显示为：???world，可以看见String类型能够正常处理，但是若出现中文需要注意处理。

再看第二个请求：

浏览器会显示报错：

它原理就是初始化RequestMappingHandlerAdapter构造函数里默认加入的那4个：

public class RequestMappingHandlerAdapter extends AbstractHandlerMethodAdapter
		implements BeanFactoryAware, InitializingBean {
    
    ...
    public RequestMappingHandlerAdapter() {
    	StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
    	stringHttpMessageConverter.setWriteAcceptCharset(false);  // see SPR-7316

    	this.messageConverters = new ArrayList<>(4);
    	this.messageConverters.add(new ByteArrayHttpMessageConverter());
    	this.messageConverters.add(stringHttpMessageConverter);
    	try {
    		this.messageConverters.add(new SourceHttpMessageConverter<>());
    	}
    	catch (Error err) {
    		// Ignore when no TransformerFactory implementation is available
    	}
    	this.messageConverters.add(new AllEncompassingFormHttpMessageConverter());
    }
    ...
}

由此可见，当我们使用Spring MVC的时候，强烈建议开启注解：@EnableWebMvc，否则功能是比较弱的。

Spring MVC的转换器匹配原理

涉及到转换器的匹配，其实就有对read的匹配和write的匹配。

Response返回向body里write时消息转换器的匹配

假设我们一个请求是返回ModelAndView。

我们知道请求交给DispatcherServlet#doDispatch方法，最终会匹配到一个HandlerAdapter然后调用其ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)方法真正处理请求，然后最终都是返回一个ModelAndView。

因为此处处理的是write过程，所以处理的是返回值。所以最终处理的是：RequestResponseBodyMethodProcessor#handleReturnValue()：

public class RequestResponseBodyMethodProcessor extends AbstractMessageConverterMethodProcessor {
    ...
    @Override
    public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
    		ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
    		throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {

    	mavContainer.setRequestHandled(true);
    	ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
    	ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);

    	// Try even with null return value. ResponseBodyAdvice could get involved.
    	// 这里找到消息转换器，来把返回的结果写进response里面~~~
    	// 该方法位于父类`AbstractMessageConverterMethodArgumentResolver`中，通用的利用转换器处理返回值的方法
    	writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage);
    }
    ...


}

Request请求read请求参数、请求body时消息转换器的匹配（本文重点）

相应的，处理请求@RequestBody的处理器选择，也发生在RequestResponseBodyMethodProcessor里

此处以这个处理器为例进行讲解：

@ResponseBody
@RequestMapping(value = "/hello/post", method = RequestMethod.POST)
public Person hello(@RequestBody Person person) {
    return person;
}

RequestResponseBodyMethodProcessor匹配入参的消息转换器

我们可以先看看RequestResponseBodyMethodProcessor这个处理器：

// @since 3.1
public class RequestResponseBodyMethodProcessor extends AbstractMessageConverterMethodProcessor {
    @Override
    public boolean supportsParameter(MethodParameter parameter) {
    	return parameter.hasParameterAnnotation(RequestBody.class);
    }
    ...
    @Override
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
    		NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {    
    	// 入参是支持使用Optional包装一层的~~~
    	parameter = parameter.nestedIfOptional();
    	// 这个方法就特别重要了，实现就在下面，现在强烈要求吧目光先投入到下面这个方法实现上~~~~
    	Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
    	// 拿到入参的形参的名字  比如此处为person
    	String name = Conventions.getVariableNameForParameter(parameter);    
    	// 下面就是进行参数绑定、数据适配、转换的逻辑了  这个在Spring MVC处理请求参数这一章会详细讲解
    	// 数据校验@Validated也是在此处生效的
    	if (binderFactory != null) {
    		WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
    		if (arg != null) {
    			validateIfApplicable(binder, parameter);
    			if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
    				throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
    			}
    		}
    		if (mavContainer != null) {
    			mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
    		}
    	}    
    	return adaptArgumentIfNecessary(arg, parameter);
    }    
    // 之前讲过writeWithMessageConverters,这个相当于读的时候进行一个消息转换器的匹配，实现逻辑大体一致~~~
    @Override
    protected <T> Object readWithMessageConverters(NativeWebRequest webRequest, MethodParameter parameter,
    		Type paramType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {    
    	HttpServletRequest servletRequest = webRequest.getNativeRequest(HttpServletRequest.class);
    	Assert.state(servletRequest != null, "No HttpServletRequest");
    	ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(servletRequest);    
    	// 核心是这个方法，它的实现逻辑在父类AbstractMessageConverterMethodArgumentResolver上~~~继续转移目光吧~~~
    	Object arg = readWithMessageConverters(inputMessage, parameter, paramType);    
    	// body体为空，而且不是@RequestBody(required = false)，那就抛错呗  请求的body是必须的  这个很好理解
    	if (arg == null && checkRequired(parameter)) {
    		throw new HttpMessageNotReadableException("Required request body is missing: " + parameter.getExecutable().toGenericString(), inputMessage);
    	}
    	return arg;
    }
}

上面已经分析到，读取的核心匹配逻辑，其实在父类AbstractMessageConverterMethodArgumentResolver#readWithMessageConverters，因此我们继续看父类的实现源码：

// @since 3.1  可议看出这个实现是处理请求request的处理器~~~
public abstract class AbstractMessageConverterMethodArgumentResolver implements HandlerMethodArgumentResolver {
    ...
    @SuppressWarnings("unchecked")
    @Nullable
    protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter,
    		Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {    
    	MediaType contentType;
    	boolean noContentType = false;
    
    	// 如果已经制定了contentType，那就没什么好说的  以你的为准
    	try {
    		contentType = inputMessage.getHeaders().getContentType();
    	}
    	catch (InvalidMediaTypeException ex) {
    		throw new HttpMediaTypeNotSupportedException(ex.getMessage());
    	}
    	// Content-Type默认值：application/octet-stream
    	if (contentType == null) {
    		noContentType = true;
    		contentType = MediaType.APPLICATION_OCTET_STREAM;
    	}    
    	// 这几句代码就是解析出入参的类型~
    	Class<?> contextClass = parameter.getContainingClass();
    	Class<T> targetClass = (targetType instanceof Class ? (Class<T>) targetType : null);
    	if (targetClass == null) {
    		ResolvableType resolvableType = ResolvableType.forMethodParameter(parameter);
    		targetClass = (Class<T>) resolvableType.resolve();
    	}    
    	HttpMethod httpMethod = (inputMessage instanceof HttpRequest ? ((HttpRequest) inputMessage).getMethod() : null);
    	Object body = NO_VALUE;    
    	EmptyBodyCheckingHttpInputMessage message;
    	try {
    		message = new EmptyBodyCheckingHttpInputMessage(inputMessage);    
    		// 这里就是匹配消息转换器的的逻辑~~~ 还是一样的  优先以GenericHttpMessageConverter这种类型的转换器为准
    		for (HttpMessageConverter<?> converter : this.messageConverters) {
    			Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass();
    			GenericHttpMessageConverter<?> genericConverter = (converter instanceof GenericHttpMessageConverter ? (GenericHttpMessageConverter<?>) converter : null);
    			if (genericConverter != null ? genericConverter.canRead(targetType, contextClass, contentType) :
    					(targetClass != null && converter.canRead(targetClass, contentType))) {
    			
    				// 因为它是一个EmptyBodyCheckingHttpInputMessage，所以它有这个判断方法  body != null表示有body内容
    				// 注意此处的判断，若有body的时候，会执行我们配置的`RequestBodyAdvice` 进行事前、时候进行处理~~~  后面我会示范
    				if (message.hasBody()) {
    					HttpInputMessage msgToUse = getAdvice().beforeBodyRead(message, parameter, targetType, converterType);
    	
    					// 执行消息转换器的read方法，从inputStream里面读出一个body出来~
    					body = (genericConverter != null ? genericConverter.read(targetType, contextClass, msgToUse) :
    							((HttpMessageConverter<T>) converter).read(targetClass, msgToUse));
    	
    					// 读出body后的事后工作~~~
    					body = getAdvice().afterBodyRead(body, msgToUse, parameter, targetType, converterType);
    				}
    		
    				// 如果没有body体，就交给handleEmptyBody来处理~~~~  第一个参数永远为null
    				// 这个处理器可以让我们给默认值，比如body为null时，我们返回一个默认的body之类的吧
    				else {
    					body = getAdvice().handleEmptyBody(null, message, parameter, targetType, converterType);
    				}
    				break;
    			}
    		}
    	}
    	catch (IOException ex) {
    		throw new HttpMessageNotReadableException("I/O error while reading input message", ex, inputMessage);
    	}    
    	// 到此处，如果body还没有被赋值过~~~~ 此处千万不能直接报错，因为很多请求它可以不用body体的
    	// 比如post请求，body里有数据。但是Content-type确实text/html 就会走这里（因为匹配不到消息转换器）
    	if (body == NO_VALUE) {
    		if (httpMethod == null || !SUPPORTED_METHODS.contains(httpMethod) || (noContentType && !message.hasBody())) {
    			return null;
    		}
    	
    		// 比如你是post方法，并且还指定了ContentType 你有body但是却没有找到支持你这种contentType的消息转换器，那肯定就报错了~~~
    		// 这个异常会被InvocableHandlerMethod catch住，虽然不会终止程序。但是会打印一个warn日志~~~
    		// 并不是所有的类型都能read的，从上篇博文可议看出，消息转换器它支持的可以read的类型还是有限的
    		throw new HttpMediaTypeNotSupportedException(contentType, this.allSupportedMediaTypes);
    	}    
    	MediaType selectedContentType = contentType;
    	Object theBody = body;
    	LogFormatUtils.traceDebug(logger, traceOn -> {
    		String formatted = LogFormatUtils.formatValue(theBody, !traceOn);
    		return "Read \"" + selectedContentType + "\" to [" + formatted + "]";
    	});    
    	return body;
    }
    ...
    

又比如我们这样子写：使用MultiValueMap是能够接收多值入参的。注意请设值Content-Type=application/x-www-form-urlencoded，这样FormHttpMessageConverter这个消息转换器可以转换它~~~

@ResponseBody
@RequestMapping(value = "/hello/post", method = RequestMethod.POST)
public Object hello(@RequestBody(required = false) MultiValueMap person) {
    return person;
}

借助RequestBodyAdvice实现对请求参数进行干预

RequestBodyAdvice它能对入参body封装的前后、空进行处理。比如下面我们就可以很好的实现日志打打印：

public class LogRequestBodyAdvice implements RequestBodyAdvice {
    @Override
    public boolean supports(MethodParameter methodParameter, Type type, Class<? extends HttpMessageConverter<?>> aClass) {
        return true;
    }
 
    @Override
    public HttpInputMessage beforeBodyRead(HttpInputMessage httpInputMessage, MethodParameter methodParameter, Type type, Class<? extends HttpMessageConverter<?>> aClass) throws IOException {
        return httpInputMessage;
    }
 
    @Override
    public Object afterBodyRead(Object o, HttpInputMessage httpInputMessage, MethodParameter methodParameter, Type type, Class<? extends HttpMessageConverter<?>> aClass) {
        Method method=methodParameter.getMethod();
        log.info("{}.{}:{}",method.getDeclaringClass().getSimpleName(),method.getName(),JSON.toJSONString(o));
        return o;
    }
 
    @Override
    public Object handleEmptyBody(Object o, HttpInputMessage httpInputMessage, MethodParameter methodParameter, Type type, Class<? extends HttpMessageConverter<?>> aClass) {
        Method method=methodParameter.getMethod();
        log.info("{}.{}",method.getDeclaringClass().getSimpleName(),method.getName());
        return o;
    }
}

这样请求的时候都能记录上日志，效率非常高，也不需要对request的body进行多次读取了。

使用@ControllerAdvice注解+RequestBodyAdvice+ResponseBodyAdvice，可以对请求的输入输出进行处理，避免了在controller中对业务代码侵入。FastJson有提供一个JSONPResponseBodyAdvice可以直接使用的。

它还有一个很不错的应用场景：就是对请求、返回数据进行加密、解密：基于RequestBodyAdvice和ResponseBodyAdvice来实现spring中参数的加密和解密

自定义消息转换器HttpMessageConverter【并让其生效】

虽然前面说了，Spring MVC已经为我们准备了好多个消息转换器了，能应付99.99%的使用场景了。

但是我们经常会遇到说不喜欢用它自带的Jackson来序列化，而想换成我们想要的国产的FastJson转换器。怎么弄呢？

其实FastJson还是非常友好的，早在@since 1.2.10版本就已经为我们写好了FastJsonHttpMessageConverter，我们直接使用即可。

Spring MVC内置支持了jackson，gson。但却没有内置支持我们国产的FastJson。

我们这样配置：

@Configuration
@EnableWebMvc
public class WebMvcConfig extends WebMvcConfigurerAdapter {


    // 请不要复写这个方法，否则你最终只有你配置的转换器，Spring MVC默认的并不会加载了~~
    //@Override
    //public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
    //    FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
    //    fastJsonHttpMessageConverter.setCharset(StandardCharsets.UTF_8);
    //    converters.add(fastJsonHttpMessageConverter);
    //}

    @Override
    public void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
        FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
        fastJsonHttpMessageConverter.setCharset(StandardCharsets.UTF_8);
        converters.add(fastJsonHttpMessageConverter);
    }
}

这样我们看到我们的转换器如下：

可以看到我们的FastJsonHttpMessageConverter已经被配置进去了。

此处我们把Handler写成这样：

@ResponseBody
@RequestMapping(value = "/hello/post", method = RequestMethod.POST)
public Object hello(@RequestBody(required = false) Person person) {
    return person;
}

我们发现不管是读还是写，最终生效的都还是MappingJackson2HttpMessageConverter，我们自定义的FastJson转换器并没有生效。相信这个原因大家都知道了：FastJson转换器排在Jackson转换器的后面，所以处理json不会生效。

那怎么解决呢？找到原因了，那就只要把自定义的消息转换器FastJsonJsonpHttpMessageConverter添加到 MappingJackson2HttpMessageConverter 前面就可以。

如果你是SpringBoot环境，你可以直接使用HttpMessageConverters很方便的把你自定义的转换器提到最高优先级，但是此处我们介绍一下Spring中的处理方式。

我们只需要这么配置就行了：

@Override
public void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
    FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
    fastJsonHttpMessageConverter.setCharset(StandardCharsets.UTF_8);

    // 把FastJsonHttpMessageConverter放到Jackson的前面去
    // 这个list是个ArrayList 所以我们要么就放在首位（不建议）,而converters.indexOf() 因为人家是new的 所以肯定是找不到此对象的位置的 所以采用遍历的方式吧
    int jacksonIndex = 0;
    for (int i = 0; i < converters.size(); i++) {
    	if (converters.get(i) instanceof MappingJackson2HttpMessageConverter) {
    		jacksonIndex = i;
    		break;
    	}
    }

    // 添加在前面
    converters.add(jacksonIndex, fastJsonHttpMessageConverter);
}

看效果：

最终效果也是没有问题的，json数据的转换工作都会被我们的FastJson接管了。

FastJsonHttpMessageConverter的坑和正确使用姿势

绝大多数情况下，直接使用FastJsonHttpMessageConverter是没有问题的。但是如果是这样的：

@ResponseBody
@RequestMapping(value = "/hello/post", method = RequestMethod.POST)
public Object hello(@RequestBody(required = false) MultiValueMap person) {
    return person;
}

请求报错如下：

JSON parse error: unsupport type interface org.springframework.util.MultiValueMap; nested exception is com.alibaba.fastjson.JSONException: unsupport type interface org.springframework.util.MultiValueMap]

我们发现报错竟然找到了FastJson的头上。说明了什么：责任链模式下，fastjson接了这个活，最终发现自己干不了，然后还抛出异常，这是明显的甩锅行为。

这个根本原因在这，看它的源码：

// 会发现FastJson这个转换器它接受所有类型它都表示可以处理~~~~
@Override
protected boolean supports(Class<?> clazz) {
    return true;
}

显然它违反了“手伸得太长的”基本原则，是需要负一定的责任的~~~~

正确使用姿势（推荐使用姿势）

为了避免误伤，其实我们配置它的时候应该限制它的作用范围，如下：

@Override
public void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
    FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
    fastJsonHttpMessageConverter.setCharset(StandardCharsets.UTF_8);

    // 这步是很重要的，让它只处理application/json这种MediaType的就没有问题了~~~~
    List<MediaType> fastMediaTypes = new ArrayList<>();
    fastMediaTypes.add(MediaType.APPLICATION_JSON_UTF8);
    fastJsonHttpMessageConverter.setSupportedMediaTypes(fastMediaTypes);

    // 把FastJsonHttpMessageConverter放到Jackson的前面去
    // 这个list是个ArrayList 所以我们要么就放在首位（不建议）,而converters.indexOf() 因为人家是new的 所以肯定是找不到此对象的位置的 所以采用遍历的方式吧
    int jacksonIndex = 0;
    for (int i = 0; i < converters.size(); i++) {
    	if (converters.get(i) instanceof MappingJackson2HttpMessageConverter) {
    		jacksonIndex = i;
    		break;
    	}
    }

    // 添加在前面
    converters.add(jacksonIndex, fastJsonHttpMessageConverter);
}

这样它就不会造成问题了，因为我们只让它处理MediaType.APPLICATION_JSON_UTF8这种类型，而这就是它最擅长的。

使用Spring MVC实现优雅的文件下载

传统的，我们要进行文件下载，可以直接操作HttpServletRequest和HttpServletResponse来处理下载。那基本上就与Spring MVC的关系不大了。 我们能看到形如下面的代码：

//设置响应头和客户端保存文件名
response.setCharacterEncoding("utf-8");
response.setContentType("application/octet-stream");
response.setHeader("Content-Disposition", "attachment;fileName=" + fileName);
...
	//打开本地文件流
	InputStream inputStream = new FileInputStream(filePath);
	//激活下载操作
	OutputStream os = response.getOutputStream();

	//循环写入输出流
	byte[] b = new byte[2048];
	int length;
	while ((length = inputStream.read(b)) > 0) {
		os.write(b, 0, length);
		downloadedLength += b.length;
	}

	// 这里主要关闭。
	os.close();
	inputStream.close();
...

显然这一大段处理起来还是比较麻烦的。本文另外一种方案：在Spring MVC环境下能让你优雅的处理文件下载：使用ResponseEntity方式。

示例如下：

// 处理下载 get/post/put请求等等都是可以的  但一般都用get请求
@RequestMapping(value = "/download", method = RequestMethod.GET)
public ResponseEntity<Resource> downloadFile(@RequestParam String fileName) {
    // 构造下载对象  读取出一个Resource出来  此处以类路径下的logback.xml
    DownloadFileInfoDto downloadFile = new DownloadFileInfoDto(fileName, new ClassPathResource("logback.xml"));
    return downloadResponse(downloadFile);
}

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
private static class DownloadFileInfoDto {
    private String fileName; // 下载的文件
    private Resource resource; // 下载的具体文件资源
}

// 共用方法  兼容到了IE浏览器~~~
private static ResponseEntity<Resource> downloadResponse(
		DownloadFileInfoDto fileInfo) {
    String fileName = fileInfo.getFileName();
    Resource body = fileInfo.getResource();    
    // ========通过User-Agent来判断浏览器类型 做一定的兼容~========
    HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
    String header = request.getHeader("User-Agent").toUpperCase();
    HttpStatus status = HttpStatus.CREATED;
    try {
    	if (header.contains("MSIE") || header.contains("TRIDENT") || header.contains("EDGE")) {
    		fileName = URLEncoder.encode(fileName, "UTF-8");
    		fileName = fileName.replace("+", "%20");    // IE下载文件名空格变+号问题
    		status = HttpStatus.OK;
    	} else { // 其它浏览器 比如谷歌浏览器等等~~~~
    		fileName = new String(fileName.getBytes("UTF-8"), "ISO8859-1");
    	}
    } catch (UnsupportedEncodingException e) {
    }

    // =====响应头需设置为MediaType.APPLICATION_OCTET_STREAM=====
    HttpHeaders headers = new HttpHeaders();
    // 注意：若这个响应头不是必须的，但是如果你确定要下载，建议写上这个响应头~
    headers.setContentType(MediaType.APPLICATION_OCTET_STREAM);
    // 此处，如果你自己没有设置这个请求头，浏览器肯定就不会弹窗对话框了。它就会以body的形式直接显示在浏览器上
    headers.setContentDispositionFormData("attachment", fileName);
    return new ResponseEntity<>(body, headers, status);
}

备注：使用此种方式最终处理返回值的处理器为：HttpEntityMethodProcessor，使用的消息转换器为：ResourceHttpMessageConverter

这样请求就能弹出下载框了。响应头如下：

可以看到这里不仅设置了Content-Disposition请求头，还设置了Content-type为application/octet- stream，那就意味着你不想让浏览器直接显示内容，而是弹出一个“文件下载”的对话框。

关于application/octet-stream等响应头的解释，请看如下例子形象解释：

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"

它表示对浏览器说：“我不清楚代码内容，请把其保存为一个文件，最好命名为picture.png”。

Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"

它表示对浏览器说：表示“这是一个PNG图像，请将其保存为一个文件，最好命名为picture.png”。

Content-Type: image/png
Content-Disposition: inline; filename="picture.png"

它表示对浏览器说：“这是一个PNG图像，除非你不知道如何显示PNG图像，否则请显示它，如果用户选择保存它，我们建议文件名保存为picture.png”。（inline方式）

在能够识别内联的浏览器中，可以使用这个方法（现在绝大多数浏览器都能识别这种方式），少数浏览器会对它进行保存~~~~

所以当你给客户端传递的不知道是文本、图片、还是其它的格式时，使用application/octet-stream最佳。（是否弹出下载框不是由它决定的，主要是Content-Disposition这个请求头来决定的）。

ResponseEntity方式对比传统Java方式

单单从代码上看ResponseEntity方式秒杀传统的Java方式，但是否我们想都不想就采用优雅方式呢？但其实非也，有些东西还是要注意的。

• 基于ResponseEntity的实现的局限性还是很大：这种下载方式是一种一次性读取的下载方式，在文件较大的时候会直接抛出内存溢出（所以适合小文件下载，不超过1G吧）。还有就是这种下载方式因为是一次性全部输出，所以无法统计已下载量、未下载量等扩展功能，所以也就不能实现断点续传。
• 传统Java通用实现在功能上能够更加的丰富：对下载文件的大小无限制（（循环读取一定量的字节写入到输出流中，因此不会造成内存溢出）。 因为是这种实现方式是基于循环写入的方式进行下载，在每次将字节块写入到输出流中的时都会进行输出流的合法性检测，在因为用户取消或者网络原因造成socket断开的时候，系统会抛出SocketWriteException。 当然我们可以捕获到这个异常，记录下当前已经下载的数据量、下载状态等。这样我们就可以实现断点续传的功能了。

ResponseEntity方式的优点就是简洁，所以在比较小的文件下载时，它绝对是首选。若是有大量的下载需求，其实一般都建议使用ftp服务器而不是http了。

当然还有一种使用ResponseEntity<byte[]>的方式，也挺优雅的，这里就只提供代码参考了：

@RequestMapping("/testResponseEntity")
public ResponseEntity<byte[]> testResponseEntity(HttpSession session) throws IOException {
    byte[] body = null;
    ServletContext servletContext = session.getServletContext();
    InputStream in = servletContext.getResourceAsStream("/files/abc.txt");
    body = new byte[in.available()];
    in.read(body);

    HttpHeaders headers = new HttpHeaders();
    headers.add("Content-Disposition","attachment;filename=abc.txt");

    HttpStatus statusCode = HttpStatus.OK;

    ResponseEntity<byte[]> response = new ResponseEntity<byte[]>(body,headers,statusCode);
    return  response;
}

此处使用的返回值处理同上，消息转换器是：ByteArrayHttpMessageConverter

自己写代码也要注意啊：代码中有顺序遍历匹配这种逻辑，或者叫责任链模式时，功能越具体的节点越是应该放在前面，功能最广最泛的节点应该放在最后面；

 

参考：

• 【小家Spring】Spring MVC容器的web九大组件之---HandlerAdapter源码详解---HttpMessageConverter的匹配规则（选择原理）