GraphQL 文件上传必须用 multipart 请求，因原生不支持二进制数据；需用 Upload! 类型、服务端异步解析XML，禁用XXE，限制文件大小并校验编码与命名空间。
GraphQL 文件上传必须用 multipart 请求
GraphQL 原生不支持文件上传，query 和 mutation 的 JSON body 无法携带二进制数据。必须改用 multipart/form-data 编码，把操作定义（operations）和文件（map）分块发送。
常见错误是直接在 mutation 中传 Base64 字符串——这会显著放大传输体积、增加内存压力、且服务端解析成本高，不推荐用于 >1MB 的文件。
- 客户端需使用
graphql-request配合FormData，或apollo-upload-client（已适配 Apollo Client v3+） - 服务端需启用 multipart 解析中间件：Apollo Server 要装
graphql-upload并调用processRequest；Nexus/Envelop 等框架也有对应插件 -
upload类型必须显式声明为Upload!（注意感叹号），不能用String或自定义 scalar 模拟
XML 数据不该塞进 GraphQL 字段传
把 XML 当作字符串字段（xmlContent: String!）提交，看似简单，实则埋下隐患：服务端无法校验结构、无法复用 XML Schema、无法流式解析大文件、也无法与现有 XML 工具链（如 XSLT、XPath）自然衔接。
真正合理的做法是「分离关注点」：GraphQL 只负责调度和元数据管理，XML 处理交给专用模块。
- 上传时用
Upload!接收文件，保存为临时路径或对象存储 URL -
后端启动异步任务（如 Celery / BullMQ）调用
libxml2、lxml或xmldom解析该 XML，提取关键字段入库或触发业务逻辑 - 若需返回 XML 片段，应封装为只读字段（如
xmlPreview），且限制长度、做字符转义，避免注入风险
结合使用的最小可行接口设计
不要试图让一个 mutation 同时完成上传 + 解析 + 存储 + 返回完整 XML 结构。拆成两步更可控：
# 步骤 1：上传
mutation UploadXml($file: Upload!) {
uploadXml(file: $file) {
id
filename
status # "uploaded" | "processing"
}
}
步骤 2：轮询或订阅结果（可选）
subscription XmlProcessingStatus($id: ID!) {
xmlProcessingStatus(id: $id) {
status # "success" | "failed"
errors
}
}
关键点：
-
uploadXmlresolver 返回后立即响应，不阻塞；XML 解析必须异步 - 避免在 resolver 中直接调用
fs.readFileSync或DOMParser.parseFromString—— Node.js 单线程会被卡住 - 如果客户端必须“同步”拿到解析结果（极少数场景），应在 mutation 中接受
timeoutMs: Int = 5000参数，内部用Promise.race控制最长等待，超时则返回status: "queued"
安全与性能容易被忽略的细节
文件上传 + XML 解析组合是典型的攻击面叠加区。以下三点常被跳过但至关重要：
- 服务端必须限制
maxFileSize（如 10MB），并在graphql-upload初始化时设置，而非仅靠 GraphQL schema 的String @length(max: 10000000) - XML 解析器必须禁用外部实体（
xxe），例如lxml要设resolve_entities=False，libxmljs要关optionParseExternalEntities - 不要把原始 XML 内容存进数据库字段（尤其是 MySQL TEXT），优先存哈希值 + 解析后的结构化数据；若必须存，确保字段类型支持 UTF-8 完整范围（如
utf8mb4）且长度足够
XML 的命名空间、编码声明、DOCTYPE 声明在上传过程中可能被篡改或丢失，解析前务必检查 是否存在且一致。
