xml 文件上传时 content-type 应设为 application/xml，因其被主流框架（如 spring boot、express）默认支持，而 text/xml 易触发中间件拦截、解析失败或 415 错误；curl 需用 -h "content-type: application/xml" --data-binary，fetch 需显式设置 headers；formdata 会强制 multipart，不可直接当 xml 解析。
XML 文件上传时 Content-Type 应该用 application/xml
绝大多数现代服务端（如 Spring Boot、Node.js Express、Nginx 代理后端）默认只接受 application/xml 作为合法的 XML 请求体类型；text/xml 虽然在 RFC 中被定义，但实际中容易触发中间件拦截、MIME 类型校验失败或自动编码转换。
-
application/xml表示“不可直接渲染的二进制语义数据”，更符合 API 场景下 XML 作为结构化载荷的本质 -
text/xml带有“可读文本”暗示，某些网关（如 AWS API Gateway）会尝试 UTF-8 BOM 处理或换行规范化，导致签名不一致或解析失败 - Spring MVC 的
@RequestBody默认只注册application/xml的HttpMessageConverter，除非显式配置支持text/xml
curl 和前端 fetch 上传时怎么设才不踩坑
手动设置 Content-Type 是最稳妥方式，别依赖浏览器自动推断 —— 它对 XML 文件几乎不识别。
- curl 示例：
curl -X POST -H "Content-Type: application/xml" --data-binary @request.xml https://api.example.com/data（注意用--data-binary避免换行符被转义） - fetch 示例：
fetch("/api", { method: "POST", headers: { "Content-Type": "application/xml" }, body: xmlString })（xmlString必须是已序列化的字符串，不是 DOM 对象） - 如果用
FormData上传 XML 文件，浏览器会强制设成multipart/form-data，此时Content-Type由边界决定，后端需按 multipart 解析，不能当纯 XML 处理
Spring Boot 接收 XML 时 Content-Type 不匹配的典型报错
错误现象通常是 415 Unsupported Media Type 或 400 Bad Request，日志里出现类似 Content type 'text/xml;charset=UTF-8' not supported。
- 检查 Controller 方法是否加了
@PostMapping(produces = "application/xml", consumes = "application/xml")——consumes必须明确写死"application/xml" - 如果用了
WebMvcConfigurer自定义消息转换器，确认Jaxb2RootElementHttpMessageConverter的supportedMediaTypes包含MediaType.APPLICATION_XML，而不是MediaType.TEXT_XML - Nginx 反向代理时，确保没加
proxy_set_header Content-Type text/xml;这类覆盖头的配置
为什么有些老系统还能用 text/xml？
因为它们用的是早期 XML-RPC 或 SOAP 1.1 栈，这些协议规范明确要求 text/xml；但这类服务现在基本只存在于遗留系统内部调用中。
- 新开发的 RESTful XML 接口、微服务间通信、云厂商 SDK，全部倾向
application/xml - 如果你必须兼容老系统，不要改客户端，而是在网关层做
Content-Type重写（比如 Envoy 的response_headers_to_add或 Nginx 的proxy_set_header） - 注意：HTTP/2 下部分客户端对
text/*类型有额外字符集协商逻辑，可能引发隐性超时或 header 截断
Content-Type 的硬性匹配逻辑。哪怕只是少一个 a，都可能卡在某一层的白名单校验里。 
