GraphQL Mutation 不支持原生文件上传，需将XML转为字符串或用multipart/form-data；字符串方案轻量但易触发请求体限制，multipart可流式处理；须捕获XML解析等异常并返回精准错误位置。
GraphQL Mutation 不支持原生文件上传
GraphQL 规范本身不定义文件上传机制，mutation 字段不能直接接收二进制数据（如 XML 文件内容）。你看到的“上传 XML 文件”实际是客户端把文件转成某种可序列化的形式，再通过 GraphQL 请求发送过去。常见做法是：把 XML 内容作为字符串传入，或走混合协议（GraphQL + multipart/form-data）。
方案一：XML 内容转为字符串传入 String 字段
最轻量、兼容性最好，适合中小 XML（"、\），否则会破坏 JSON 传输结构。
- 客户端需先读取 XML 文件为文本，用
XMLSerializer（浏览器）或fs.readFileSync(..., 'utf8')（Node.js）获取字符串 - GraphQL mutation 定义字段类型为
String!，例如：mutation UploadXml($content: String!) { uploadXml(content: $content) { id status } } - 服务端 resolver 直接用标准 XML 解析器（如 Node.js 的
libxmljs或fast-xml-parser）处理该字符串 - 注意：若 XML 含有 CDATA 或特殊命名空间，确保解析器配置支持；某些精简 parser（如
xml2js默认不保留空格/注释）可能丢失结构信息
方案二：用 graphql-multipart-request-spec 支持真正的二进制上传
这是目前社区事实标准（被 Apollo、URQL、GraphQL Yoga 等广泛支持），允许在同一个请求中同时发送 GraphQL 操作和文件二进制块。XML 文件以 Upload 标量类型传递，服务端收到的是流或临时文件句柄。
- 服务端需启用 multipart 支持：例如 Apollo Server 要装
@apollo/server-plugin-upload，并确保uploads: true（v4+ 默认开启） - schema 中定义标量：
scalar Upload type Mutation { uploadXml(file: Upload!): XmlUploadResult! } - 客户端必须用支持 multipart 的 client（如
apollo-upload-client），调用时传File对象（浏览器）或ReadStream（Node.js），不是字符串 - resolver 中拿到的是类似
{ createReadStream(), filename, mimetype }的对象，需自行读取流并保存或解析 —— 注意：mimetype应校验为text/xml或application/xml，防止上传恶意二进制
为什么不用 Base64 编码再传？
Base64 把 3 字节变成 4 字节，体积膨胀约 33%，且增加客户端和服务端编解码开销。对 >2MB 的 XML，内存占用和 GC 压力明显上升。更严重的是：GraphQL 请求体变大后，容易触发网关或 CDN 的请求体大小限制（如 Nginx 默认 client_max_body_size 1m），而 multipart 可流式处理，绕过该瓶颈。
除非你受限于无法修改服务端上传中间件（比如只跑在纯 REST 代理后面），否则不要主动选 Base64。
真正容易被忽略的是错误边界：XML 解析失败（格式错误、编码声明不匹配、外部 DTD 引用）、上传超时、服务端磁盘满、甚至客户端把 UTF-8 XML 当作 Latin-1 读取再传——这些都会导致看似成功的 mutation 返回模糊的 500 或空响应。务必在 resolver 中捕获 XML 解析异常，并返回带位置信息的错误（如 line 42, column 17），而不是吞掉或泛化成 “invalid input”。
