如前所述，为了使框架选择适当的MessageConverter，它需要参数类型以及（可选）内容类型信息。选择适当的MessageConverter的逻辑驻留在参数解析器（HandlerMethodArgumentResolvers）中，该解析器在调用用户定义的处理程序方法之前（即当框架知道实际的参数类型时）触发。如果参数类型与当前有效负载的类型不匹配，则框架将委派给预先配置的MessageConverters的堆栈，以查看其中是否有一个可以转换有效负载。如您所见，MessageConverter的Object fromMessage(Message<?> message, Class<?> targetClass);操作将targetClass作为其参数之一。该框架还确保提供的Message始终包含一个contentType头。当没有contentType标头时，它会插入按绑定的contentType标头或默认的contentType标头。contentType参数类型的组合是框架确定消息是否可以转换为目标类型的机制。如果找不到合适的MessageConverter，则会引发异常，您可以通过添加自定义MessageConverter来处理该异常（请参见“用户定义的消息转换器”）。

但是，如果有效载荷类型与处理程序方法声明的目标类型匹配，该怎么办？在这种情况下，没有任何要转换的内容，并且有效载荷未经修改地传递。尽管这听起来很简单且合乎逻辑，但请记住以Message<?>或Object作为参数的处理程序方法。通过将目标类型声明为Object（在Java中为instanceof，是所有内容），实际上就放弃了转换过程。

 不要期望仅根据contentType将Message转换为其他类型。请记住，contentType是目标类型的补充。如果需要，您可以提供一个提示，MessageConverter可能会也可能不会考虑。