XML上传接口不能直接套用JSON限流策略，因XML解析成本高，网关未解析前无法可靠提取userId等字段；强行按请求头或路径限流会漏维度，解析后再限流则失去前置拦截意义。
XML上传接口为什么不能直接套用JSON限流策略
因为XML解析成本远高于JSON，网关在未解析前无法可靠提取userId或clientId等限流维度字段。若强行按请求头或路径限流，会漏掉关键业务维度；若等解析完再限流，又失去网关前置拦截的意义。
实操建议：
- 在API网关层启用
XML body inspection（如Kong的request-transformer插件 + 自定义Lua逻辑，或AWS API Gateway的XML path extraction配置），只提取顶层标签如<order_id></order_id>或<tenant_id></tenant_id>，不全文解析 - 避免用XPath匹配嵌套深层节点——网关性能扛不住，改用固定路径如
/root/header/tenantId - 限流键（rate limit key）优先拼接
tenantId + clientIP，而非单用clientIP，防止多租户间互相挤占配额
XML响应缓存必须绕过Content-Type协商陷阱
很多网关默认只缓存Content-Type: application/json响应，而XML接口常返回text/xml或application/xml，导致缓存开关开着却完全不生效。
实操建议：
- 显式在缓存策略中声明支持的MIME类型，例如在Envoy中配置
content_type_matcher包含text/xml和application/xml - XML响应必须带
ETag或Last-Modified，且网关需开启cache_validation（否则304不触发，重复返回200+完整body） - 禁止缓存含
<timestamp></timestamp>、<nonce></nonce>等动态字段的XML——先用response-transformer插件剥离这些节点再缓存
基于XML签名的认证为何比OAuth2更适合作为上游校验
XML上传常来自传统企业系统（如SAP、Oracle EBS），它们不支持OAuth2流程，但普遍具备WS-Security能力。网关若硬推Bearer Token，会导致对接方重写整个调用栈。
实操建议：
- 在网关层验证
<signature></signature>节点：检查X509Certificate是否在白名单内、SignedInfo哈希是否匹配、ReferenceURI是否指向id="body"等固定锚点 - 签名验证失败时，返回标准SOAP Fault：
<soap:Fault> <faultcode>soap:Security</faultcode> <faultstring>Invalid XML signature</faultstring> </soap:Fault>
- 不要把公钥硬编码进网关配置——通过
keycloak-adapter或自建/certs/{tenant}端点动态拉取，避免每次证书轮换都要重启网关
大XML文件上传时网关与后端的超时和分块处理对齐
网关设了60秒超时，后端服务却要花90秒处理一个10MB的<invoicebatch></invoicebatch>，结果网关提前断连，后端继续执行却无人接收结果——这是最典型的“假失败”场景。
实操建议：
- 网关侧关闭
timeout，改用max_request_body_size（如100MB）+streaming_mode: true，让XML流式透传 - 后端必须实现
multipart/form-data或chunked transfer encoding支持，不能依赖一次性读完request.body - 上传成功后，网关应注入
X-Upload-ID头并返回202 Accepted，后续用该ID轮询/status/{id}查处理结果，而不是等同步响应
<item><category></category></item>限流），都应该下沉到业务服务里做，别强塞给网关。 
