XML上传触发413错误主因是HTTP服务器（如Nginx）或后端（如Spring Boot）对请求体大小设限，XML文件超出阈值；需分别调整Nginx的client_max_body_size、Spring Boot的server.tomcat.max-http-form-post-size等多层限制。
为什么XML上传会触发413错误
413错误不是XML本身的问题，而是HTTP服务器（如Nginx、Apache）或后端应用（如Spring Boot、Django）对请求体大小做了默认限制，而你的XML文件超出了这个阈值。常见于上传大型配置文件、SOAP消息、GIS数据或批量导出的业务数据。
Nginx中调整client_max_body_size
这是最常被忽略的环节——即使后端已放开限制，Nginx仍可能在代理层就拦截请求。需在http、server或location块中显式设置：
http {
client_max_body_size 50M;
}
server {
location /api/upload {
client_max_body_size 100M;
proxy_pass http://backend;
}
}
注意：client_max_body_size必须放在能覆盖到该请求路径的配置层级；修改后需执行nginx -t && nginx -s reload生效；若使用Docker部署，还要确认宿主机挂载的配置文件是否被正确覆盖。
Spring Boot中解除Spring MVC和Tomcat双重限制
Spring Boot 2.0+ 默认同时受spring.servlet.multipart.max-file-size（针对文件）和server.tomcat.max-http-form-post-size（针对所有POST body）约束。XML上传通常走的是原始RequestBody而非MultipartFile，所以重点是后者：
- 若用内嵌Tomcat：在
application.yml中设server.tomcat.max-http-form-post-size: 104857600（单位字节，即100MB） - 若XML通过
@RequestBody String xml接收，还需检查spring.mvc.max-request-size（Spring Boot 2.6+ 引入，替代旧的max-http-header-size相关项） - 若启用WebMvcConfigurer自定义
HttpMessageConverter，确保未意外套用StringHttpMessageConverter的默认字符长度限制
客户端发送时避免Content-Type陷阱
很多前端代码用fetch或axios发XML，但手动设置Content-Type: text/xml或application/xml后，若没禁用自动添加charset，某些服务端解析器（如老版本Jetty）会因不识别charset=UTF-8后缀而拒绝请求，间接导致超时或误判为非法载荷，最终返回413。稳妥做法是：
- 显式传入
Blob或ArrayBuffer，不依赖FormData - 避免手动拼接
Content-Type头，让浏览器自动推导（如传new Blob([xmlStr], {type: 'application/xml'})） - 若必须设头，用
application/xml;charset=UTF-8而非text/xml（后者在部分中间件中触发更严格的body校验）
真正卡住的地方往往不在单点配置，而在于Nginx、Spring、JVM启动参数（如-Dorg.apache.tomcat.util.http.parser.HttpParser.MAX_HEADER_SIZE）、甚至云WAF（如Cloudflare有独立的100MB body上限）层层叠加的限制。逐层验证比盲目调大更有效。
