HandlerMethodArgumentResolver(三)：基于HttpMessageConverter消息轉換器的參數解析器【享學Spring MVC】

每篇一句

一個事實是：對于大多數技術，了解隻需要一天，簡單搞起來隻需要一周。入門可能隻需要一個月

前言

通過前面兩篇文章的介紹，相信你對

HandlerMethodArgumentResolver

了解已經很深刻了。但是你或許和我一樣還有一種感覺，似乎還缺點什麼：

我們使用非常頻繁的

@RequestBody

是怎麼封裝請求體的呢？？？這塊使用非常廣泛的地方卻還木有講解到，因為它的處理方式和前面的不太一樣，是以單摘出來到本文進行較長的描述。

第四類：基于 `ContentType` 消息轉換器類型

利用 HttpMessageConverter 将輸入流轉換成對應的參數

這類參數解析器的基類是

AbstractMessageConverterMethodArgumentResolver

：

// @since 3.1
public abstract class AbstractMessageConverterMethodArgumentResolver implements HandlerMethodArgumentResolver {

	// 預設支援的方法（沒有Deleted方法）
	// httpMethod為null 或者方法不屬于這集中 或者沒有contendType且沒有body 那就傳回null
	// 也就是說如果是Deleted請求，即使body裡有值也是傳回null的。（因為它不是SUPPORTED_METHODS ）
	private static final Set<HttpMethod> SUPPORTED_METHODS = EnumSet.of(HttpMethod.POST, HttpMethod.PUT, HttpMethod.PATCH);
	private static final Object NO_VALUE = new Object();

	protected final List<HttpMessageConverter<?>> messageConverters;
	protected final List<MediaType> allSupportedMediaTypes;
	// 和RequestBodyAdvice和ResponseBodyAdvice有關的
	private final RequestResponseBodyAdviceChain advice;

	// 構造函數裡指定HttpMessageConverter
	// 此一個參數的構造函數木人調用
	public AbstractMessageConverterMethodArgumentResolver(List<HttpMessageConverter<?>> converters) {
		this(converters, null);
	}

	// @since 4.2
	public AbstractMessageConverterMethodArgumentResolver(List<HttpMessageConverter<?>> converters, @Nullable List<Object> requestResponseBodyAdvice) {
		Assert.notEmpty(converters, "'messageConverters' must not be empty");
		this.messageConverters = converters;
		// 它會把所有的消息轉換器裡支援的MediaType都全部拿出來彙聚起來~
		this.allSupportedMediaTypes = getAllSupportedMediaTypes(converters);
		this.advice = new RequestResponseBodyAdviceChain(requestResponseBodyAdvice);
	}

	// 提供一個defualt方法通路
	RequestResponseBodyAdviceChain getAdvice() {
		return this.advice;
	}

	// 子類RequestResponseBodyMethodProcessor有複寫此方法
	@Nullable
	protected <T> Object readWithMessageConverters(NativeWebRequest webRequest, MethodParameter parameter, Type paramType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {

		HttpInputMessage inputMessage = createInputMessage(webRequest);
		return readWithMessageConverters(inputMessage, parameter, paramType);
	}
	...
}

說明：此抽象類并沒有實作

resolveArgument()

這個接口方法，而隻是提供了一些

protected

方法，作為工具方法給子類調用，比如最為重要的這個方法：

readWithMessageConverters()

就是利用消息轉換器解析

HttpInputMessage

的核心。

關于此抽象類的描述，可以看這裡，HttpMessageConverter比對規則

它的繼承樹如下：

HandlerMethodArgumentResolver(三)：基于HttpMessageConverter消息轉換器的參數解析器【享學Spring MVC】

RequestPartMethodArgumentResolver

它用于解析參數被

@RequestPart

修飾，或者參數類型是

MultipartFile | Servlet 3.0提供的javax.servlet.http.Part

類型（并且沒有被

@RequestParam

修飾），資料通過

HttpServletRequest

擷取

當屬性被标注為

@RequestPart

的話，那就會經過

HttpMessageConverter

結合

Content-Type

來解析，這個效果特别像

@RequestBody

的處理方式~

// @since 3.1
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RequestPart {
	@AliasFor("name")
	String value() default "";
	@AliasFor("value")
	String name() default "";
	boolean required() default true;
}

// @since 3.1
public class RequestPartMethodArgumentResolver extends AbstractMessageConverterMethodArgumentResolver {

	// 标注了@RequestPart注解的
	// 沒有标注@RequestPart并且也沒有标注@RequestParam，但是是Multipart類型的也會處理
	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		if (parameter.hasParameterAnnotation(RequestPart.class)) {
			return true;
		} else {
			if (parameter.hasParameterAnnotation(RequestParam.class)) {
				return false;
			}
			return MultipartResolutionDelegate.isMultipartArgument(parameter.nestedIfOptional());
		}
	}

	@Override
	@Nullable
	public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
			NativeWebRequest request, @Nullable WebDataBinderFactory binderFactory) throws Exception {

		HttpServletRequest servletRequest = request.getNativeRequest(HttpServletRequest.class);
		Assert.state(servletRequest != null, "No HttpServletRequest");

		RequestPart requestPart = parameter.getParameterAnnotation(RequestPart.class);
		boolean isRequired = ((requestPart == null || requestPart.required()) && !parameter.isOptional());

		// 如果注解沒有指定，就取形參名
		String name = getPartName(parameter, requestPart);
		parameter = parameter.nestedIfOptional();
		Object arg = null;

		// resolveMultipartArgument這個方法隻處理：
		// MultipartFile類型以及對應的數組/集合類型
		// Part類型以及對應的數組集合類型
		// 若形參類型不是以上類型，傳回UNRESOLVABLE（空對象）

		// 最終傳回StandardMultipartHttpServletRequest/request.getParts()[0]等~
		Object mpArg = MultipartResolutionDelegate.resolveMultipartArgument(name, parameter, servletRequest);
		if (mpArg != MultipartResolutionDelegate.UNRESOLVABLE) {
			arg = mpArg; // 是part類型，那就直接指派吧
		} else { // 其它類型
			...
		}
		...
	}
}

此處理器用于解析

@RequestPart

參數類型，它和多部分檔案上傳有關。關于

Spring MVC

中的檔案上傳，此處就不便展開了。後面有個專題專門講解

Spring MVC

中的上傳、下載下傳~

AbstractMessageConverterMethodProcessor（重點）

命名為

Processor

說明它既能處理入參，也能處理傳回值，當然本文的關注點是方法入參（和

HttpMessageConverter

相關）。

請求body體一般是一段字元串/位元組流，查詢參數可以看做URL的一部分，這兩個是位于請求封包的不同地方。

表單參數可以按照一定格式放在請求體中，也可以放在url上作為查詢參數。

響應body體則是response傳回的具體内容，對于一個普通的html頁面，body裡面就是頁面的源代碼。對于

HttpMessage

響應體裡可能就是個json串（但無強制要求）。

響應體一般都會結合 Content-Type 一起使用，告訴用戶端隻有知道這個頭了才知道如何渲染。

AbstractMessageConverterMethodProcessor

源碼稍顯複雜，它和Http協定、内容協商有很大的關聯：

// @since 3.1
public abstract class AbstractMessageConverterMethodProcessor extends AbstractMessageConverterMethodArgumentResolver implements HandlerMethodReturnValueHandler {

	// 預設情況下：檔案們字尾是這些就不彈窗下載下傳
	private static final Set<String> WHITELISTED_EXTENSIONS = new HashSet<>(Arrays.asList("txt", "text", "yml", "properties", "csv",
			"json", "xml", "atom", "rss", "png", "jpe", "jpeg", "jpg", "gif", "wbmp", "bmp"));
	private static final Set<String> WHITELISTED_MEDIA_BASE_TYPES = new HashSet<>(Arrays.asList("audio", "image", "video"));
	private static final List<MediaType> ALL_APPLICATION_MEDIA_TYPES = Arrays.asList(MediaType.ALL, new MediaType("application"));
	private static final Type RESOURCE_REGION_LIST_TYPE = new ParameterizedTypeReference<List<ResourceRegion>>() { }.getType();
	
	// 用于給URL解碼 decodingUrlPathHelper.decodeRequestString(servletRequest, filename);
	private static final UrlPathHelper decodingUrlPathHelper = new UrlPathHelper();
	// rawUrlPathHelper.getOriginatingRequestUri(servletRequest);
	private static final UrlPathHelper rawUrlPathHelper = new UrlPathHelper();
	static {
		rawUrlPathHelper.setRemoveSemicolonContent(false);
		rawUrlPathHelper.setUrlDecode(false);
	}

	// 内容協商管理器
	private final ContentNegotiationManager contentNegotiationManager;
	// 擴充名的内容協商政策
	private final PathExtensionContentNegotiationStrategy pathStrategy;
	private final Set<String> safeExtensions = new HashSet<>();

	protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters) {
		this(converters, null, null);
	}
	// 可以指定内容協商管理器ContentNegotiationManager 
	protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters, @Nullable ContentNegotiationManager contentNegotiationManager) {
		this(converters, contentNegotiationManager, null);
	}
	// 這個構造器才是重點
	protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters, @Nullable ContentNegotiationManager manager, @Nullable List<Object> requestResponseBodyAdvice) {
		super(converters, requestResponseBodyAdvice);

		// 可以看到：預設情況下會直接new一個
		this.contentNegotiationManager = (manager != null ? manager : new ContentNegotiationManager());
		// 若管理器裡有就用管理器裡的，否則new PathExtensionContentNegotiationStrategy()
		this.pathStrategy = initPathStrategy(this.contentNegotiationManager);

		// 用safeExtensions裝上内容協商所支援的所有字尾
		// 并且把字尾白名單也加上去（表示是預設支援的字尾）
		this.safeExtensions.addAll(this.contentNegotiationManager.getAllFileExtensions());
		this.safeExtensions.addAll(WHITELISTED_EXTENSIONS);
	}

	// ServletServerHttpResponse是對HttpServletResponse的包裝，主要是對響應頭進行處理
	// 主要是處理：setContentType、setCharacterEncoding等等
	// 是以子類若要寫資料，就調用此方法來向輸出流裡寫吧~~~
	protected ServletServerHttpResponse createOutputMessage(NativeWebRequest webRequest) {
		HttpServletResponse response = webRequest.getNativeResponse(HttpServletResponse.class);
		Assert.state(response != null, "No HttpServletResponse");
		return new ServletServerHttpResponse(response);
	}

	// 注意：createInputMessage()方法是父類提供的，對HttpServletRequest的包裝
	// 主要處理了：getURI()、getHeaders()等方法
	// getHeaders()方法主要是處理了：getContentType()...


	protected <T> void writeWithMessageConverters(T value, MethodParameter returnType, NativeWebRequest webRequest) throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {
		ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
		ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);
		writeWithMessageConverters(value, returnType, inputMessage, outputMessage);
	}

	// 這個方法省略
	// 這個方法是消息處理的核心之核心：處理了contentType、消息轉換、内容協商、下載下傳等等
	// 注意：此處并且還會執行RequestResponseBodyAdviceChain，進行前後攔截
	protected <T> void writeWithMessageConverters(@Nullable T value, MethodParameter returnType,
			ServletServerHttpRequest inputMessage, ServletServerHttpResponse outputMessage)
			throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException { ... }
}

本類的核心是各式各樣的

HttpMessageConverter

消息轉換器，因為最終的write都是交給它們去完成。

此抽象類裡，它完成了内容協商~

關于内容協商的詳解，強烈建議你點選這裡。另外這篇文章也深入的分析了 AbstractMessageConverterMethodProcessor 這個類，可以作為參考。

既然父類都已經完成了這麼多事，那麼子類自然就非常的簡單的。看看它的兩個具體實作子類：

RequestResponseBodyMethodProcessor

顧名思義，它負責處理

@RequestBody

這個注解的參數

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 {

		parameter = parameter.nestedIfOptional();
		// 是以核心邏輯：讀取流、消息換換等都在父類裡已經完成。子類直接調用就可以拿到轉換後的值arg 
		// arg 一般都是個類對象。比如Person執行個體
		Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
		// 若是POJO，就是類名首字母小寫（并不是形參名）
		String name = Conventions.getVariableNameForParameter(parameter);

		// 進行資料校驗（之前已經詳細分析過，此處一筆帶過）
		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());
				}
			}

			// 把校驗結果放進Model裡，友善頁面裡擷取
			if (mavContainer != null) {
				mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
			}
		}

		// 适配：支援到Optional類型的參數
		return adaptArgumentIfNecessary(arg, parameter);
	}
}

HttpEntityMethodProcessor

用于處理

HttpEntity

和

RequestEntity

類型的入參的。

public class HttpEntityMethodProcessor extends AbstractMessageConverterMethodProcessor {
	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		return (HttpEntity.class == parameter.getParameterType() || RequestEntity.class == parameter.getParameterType());
	}

	@Override
	@Nullable
	public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
			NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws IOException, HttpMediaTypeNotSupportedException {

		ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
		// 拿到HttpEntity的泛型類型
		Type paramType = getHttpEntityType(parameter);
		if (paramType == null) {
			// 注意：這個泛型類型是必須指定的，必須的
			throw new IllegalArgumentException("HttpEntity parameter '" + parameter.getParameterName() + "' in method " + parameter.getMethod() + " is not parameterized");
		}

		// 調用父類方法拿到body的值(把泛型類型傳進去了，是以傳回的是個執行個體)
		Object body = readWithMessageConverters(webRequest, parameter, paramType);
		// 注意步操作：new了一個RequestEntity進去，持有執行個體即可
		if (RequestEntity.class == parameter.getParameterType()) {
			return new RequestEntity<>(body, inputMessage.getHeaders(), inputMessage.getMethod(), inputMessage.getURI());
		} else { // 用的父類HttpEntity，那就會丢失掉Method等資訊（是以建議入參用RequestEntity類型，更加強大些）
			return new HttpEntity<>(body, inputMessage.getHeaders());
		}
	}
}

注意：這裡可沒有validate校驗了，這也是經常被面試問到的：使用 HttpEntity @RequestBody 有什麼差別呢？

從代碼裡可以直覺的看到：有了抽象父類後，子類需要做的事情已經很少了，隻需要比對參數類型、做不同的傳回而已。

關于它倆的使用案例，此處不用再展示了，因為各位平時工作中都在使用，再熟悉不過了。但針對他倆的使用，我總結出如下幾個小細節，供以參考：

@RequestBody / HttpEntity 它的參數（泛型）類型允許是Map
方法上的和類上的 @ResponseBody 都可以被繼承，但 @RequestBody 不可以
@RequestBody 它自帶有 Bean Validation 校驗能力（當然需要啟用）， HttpEntity 更加的輕量和友善

HttpEntity/RequestEntity 所在包是： org.springframework.http ，屬于spring-web @RequestBody 位于 org.springframework.web.bind.annotation ，同樣屬于spring-web

最後還落了一個

ErrorsMethodArgumentResolver

，在這裡補充一下：

ErrorsMethodArgumentResolver

它用于在方法參數可以寫

Errors

類型，來拿到資料校驗結果。

public class ErrorsMethodArgumentResolver implements HandlerMethodArgumentResolver {
	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		Class<?> paramType = parameter.getParameterType();
		return Errors.class.isAssignableFrom(paramType);
	}

	@Override
	@Nullable
	public Object resolveArgument(MethodParameter parameter,
			@Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest,
			@Nullable WebDataBinderFactory binderFactory) throws Exception {

		Assert.state(mavContainer != null,
				"Errors/BindingResult argument only supported on regular handler methods");

		ModelMap model = mavContainer.getModel();
		String lastKey = CollectionUtils.lastElement(model.keySet());
		
		// 隻有@RequestBody/@RequestPart注解的  這裡面才會有值
		if (lastKey != null && lastKey.startsWith(BindingResult.MODEL_KEY_PREFIX)) {
			return model.get(lastKey);
		}

		// 簡單的說：必須有@RequestBody/@RequestPart這注解标注，Errors參數才有意義
		throw new IllegalStateException(
				"An Errors/BindingResult argument is expected to be declared immediately after " +
				"the model attribute, the @RequestBody or the @RequestPart arguments " +
				"to which they apply: " + parameter.getMethod());
	}
}

Spring MVC參數處理器的注冊與順序

到這裡，一個不落的把

Spring MVC

内置提供的參數處理器

ArgumentResolver

說了個遍。

前面我有提到過：參數處理對處理器的順序是敏感的，是以我們需要關注

Spring MVC

最終的執行順序，這時候我們的聚合容器

HandlerMethodArgumentResolverComposite

就出場了：

public class HandlerMethodArgumentResolverComposite implements HandlerMethodArgumentResolver {

	private final List<HandlerMethodArgumentResolver> argumentResolvers = new LinkedList<>();
	// 具有緩存
	private final Map<MethodParameter, HandlerMethodArgumentResolver> argumentResolverCache = new ConcurrentHashMap<>(256);	
	...
	// @since 4.3  木有任何地方調用
	public void clear() {
		this.argumentResolvers.clear();
	}

	// getArgumentResolver()方法是本文的核心
	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		return getArgumentResolver(parameter) != null;
	}
	@Override
	@Nullable
	public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
		
		// 這裡是關鍵：每個參數最多隻會被一個處理器處理
		HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter);
		if (resolver == null) {
			throw new IllegalArgumentException("Unsupported parameter type [" + parameter.getParameterType().getName() + "]." + " supportsParameter should be called first.");
		}
		return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
	}
	
	...	

	// 這塊邏輯保證了每個parameter參數最多隻會被一個處理器處理
	// 這個從緩存的資料結構中也能夠看出來的
	@Nullable
	private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {
		HandlerMethodArgumentResolver result = this.argumentResolverCache.get(parameter);
		if (result == null) {
			for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) {
				if (methodArgumentResolver.supportsParameter(parameter)) {
					result = methodArgumentResolver;
					this.argumentResolverCache.put(parameter, result);
					break;
				}
			}
		}
		return result;
	}
}

預設情況

Spring MVC

注冊的處理器（順序）如下：

它初始化處的代碼如下：

RequestMappingHandlerAdapter：
	@Override
	public void afterPropertiesSet() {
		...
		// 26個，詳見方法getDefaultArgumentResolvers
		if (this.argumentResolvers == null) {
			List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
			this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
		}
		// 12個  詳見方法getDefaultInitBinderArgumentResolvers
		if (this.initBinderArgumentResolvers == null) {
			List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers();
			this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
		}
		...
	}

注意：這裡面

initBinderArgumentResolvers

最終隻會有12個處理器，因為它的注冊方法如下截圖（也是這個順序）：

前面有提到過說标注有

@InitBInder

注解裡也可以寫很多類型的參數，但因為它隻會有12個處理器，是以有些參數它是不能寫的（比如

@RequestBody

、

Errors

等等這種都是不能寫的），不用一一枚舉，做到心中有數就成。

總結

本文介紹的處理内容，其實還是比較重要的，因為它和消息轉換器

HttpMessageConverter

有關，畢竟它是我們目前主流的使用方式，希望可以幫助到大家了解。

這裡可以提前預告一下：下篇文章将非常重要，因為我将結合實際場景，示範一個我們通過自定義

HandlerMethodArgumentResolver

實作的特殊場景的解決方案，非常的優雅和值得推廣，有興趣者可持續關注

HandlerMethodArgumentResolver(三)：基于HttpMessageConverter消息轉換器的參數解析器【享學Spring MVC】

每篇一句

前言

第四類：基于 `ContentType` 消息轉換器類型

RequestPartMethodArgumentResolver

AbstractMessageConverterMethodProcessor（重點）

RequestResponseBodyMethodProcessor

HttpEntityMethodProcessor

Spring MVC參數處理器的注冊與順序

總結

相關閱讀

繼續閱讀

使用@Async異步注解導緻該Bean在循環依賴時啟動報BeanCurrentlyInCreationException異常的根本原因分析，以及提供解決方案【享學Spring】關注A哥

Springboot中@RequestBody接收的對象傳入首字母大寫的參數時，無法接收到參數值的問題解決解決方法：

@Validated和@Valid的差別？教你使用它完成Controller參數校驗（含級聯屬性校驗）以及原理分析【享學Spring】關注A哥

SpringMVC接收複雜參數的處理方法

@RequestParam和@PathVariable以及@RequestBody的差別和使用

json資料互動——@RequestBody與@ResponseBody

@RequestBody、@ResponseBody的具體用法和使用時機

Spring 常用注解 @RequestMapping @ResponseBody 和 @RequestBody 注解的用法與差別

SpringMVC中使用@RequestBody,@ResponseBody注解實作Java對象和XML/JSON資料自動轉換（上）...

【小家Spring】聊聊Spring中的資料轉換：Converter、ConversionService、TypeConverter、PropertyEditor關注A哥

從原理層面掌握@ModelAttribute的使用（核心原理篇）【享學Spring MVC】關注A哥

HandlerMethodArgumentResolver(二)：Map參數類型和固定參數類型【享學Spring MVC】關注A哥

ContentNegotiation内容協商機制(一)---Spring MVC内置支援的4種内容協商方式【享學Spring MVC】關注A哥

@requestbody和@requestparam到底什麼作用1、什麼都不寫2、使用@RequestParam3、使用@RequestBody總結

ajax送出及Spring接收

Springboot 最細節全面的接口傳參接參介紹，總有你喜歡的一種方式

HandlerMethodArgumentResolver(三)：基于HttpMessageConverter消息轉換器的參數解析器【享學Spring MVC】

每篇一句

前言

第四類：基于 ContentType 消息轉換器類型

RequestPartMethodArgumentResolver

AbstractMessageConverterMethodProcessor（重點）

RequestResponseBodyMethodProcessor

HttpEntityMethodProcessor

Spring MVC參數處理器的注冊與順序

總結

相關閱讀

繼續閱讀

第四類：基于 `ContentType` 消息轉換器類型