XML上传失败报413或连接重置是请求体超限所致，因XML冗余大、多层代理（Nginx/Spring Boot/Tomcat）限制未同步调整，且解析失败实为传输截断而非逻辑错误。
XML上传失败报413或连接被重置
这是典型的请求体超限问题，Nginx、Apache 或后端框架（如 Spring Boot、Express）默认限制了允许接收的请求体大小，而 XML 文件常含大量冗余空格、缩进和命名空间声明，实际体积比看起来大得多。
关键不是“XML 特别难传”，而是它容易在不察觉时突破默认阈值。比如一个 2MB 的 report.xml，经 UTF-8 编码+XML 声明+注释后，HTTP body 可能接近 2.3MB，刚好卡在 Nginx 默认的 1MB 临界点上。
- Nginx：检查
client_max_body_size，需在http、server或location块中显式设置，仅改http不一定生效——如果 upload 路由落在独立location里，必须在那里覆盖 - Spring Boot：
spring.servlet.multipart.max-request-size和spring.servlet.multipart.max-file-size都要调，且 2.0+ 版本后这两个配置已取代旧的multipart.maxFileSize - Express + multer：不能只设
limits.fileSize，还得同步配limits.fieldSize（XML 中的 base64 内容或大文本字段会走这里）
为什么调了 Nginx 还是 413？
常见原因是多层代理未同步调整。比如 Nginx → Spring Boot → Tomcat，三者都有独立限制，漏掉任意一层都会截断。
- Nginx 日志里搜
413 Request Entity Too Large，确认是否真来自它；没有就说明拦截发生在下游 - Spring Boot 启动时加
--debug，看日志是否打印MultipartConfigElement初始化参数，验证配置是否加载成功 - Tomcat 9+ 内嵌时，
server.tomcat.max-http-form-post-size已废弃，实际受spring.servlet.multipart控制；但若单独部署 war 包，仍需检查conf/server.xml中maxPostSize（单位是字节，设为-1表示不限）
上传后 XML 解析失败，内容不完整
这不是解析逻辑的问题，是 Body 在传输中途被截断，导致 XML 格式损坏。典型现象是解析器报 XMLStreamException: Premature end of file 或 ParseError: no element found。
- 用
curl -v上传时加--data-binary @file.xml，避免 shell 对特殊字符误处理；别用-d，它会 URL 编码并可能丢掉空格和换行 - 前端发请求时，确保
Content-Type是application/xml或text/xml，不要用multipart/form-data包一层再塞 XML 字符串——这会让 body 变得更大，还增加解析复杂度 - 若必须走 multipart（例如同时传 XML + 其他字段），后端接收时别用
request.getInputStream()直读，应使用框架提供的 multipart 解析器（如 Spring 的@RequestPart），否则容易漏读 boundary 后的数据
大 XML 上传的隐性开销
单纯调大限制只是治标。XML 解析本身内存占用高，DOM 解析器会把整个文档载入内存，一个 10MB XML 可能吃掉 50MB+ 堆内存，还可能触发 GC 暂停。
- 生产环境建议改用 SAX 或 StAX 流式解析，尤其当只需提取其中几个字段时
- 如果上传频率高，考虑加个前置校验：Nginx 用
lua-resty-limit-traffic限速，或在 API 网关层对Content-Length做快速拦截（注意：部分客户端不发该 header，需配合Transfer-Encoding: chunked处理） - 别忘了配好超时：
client_header_timeout、client_body_timeout（Nginx），以及后端的connection-timeout，否则大文件上传卡住时，连接会僵死很久
真正麻烦的从来不是改哪一行配置，而是得摸清整个链路上每个组件怎么咬合、谁在悄悄截断、谁又在默默放大开销。
