soap with attachments（swa）是一种用mime multipart/related包装soap消息与二进制附件的约定，避免base64编码导致的体积膨胀和解析开销，但因互操作性差、生态支持弱，已被mtom和rest替代。
SOAP with Attachments（SwA）不是新协议，而是一种**用标准 MIME 多部分（multipart/related）包装 SOAP 消息 + 二进制附件的约定**。它把 XML 的 Envelope 当作一个 part，把图片、PDF、ZIP 等原始二进制文件当作其他 parts，再用 Content-ID 和 href="cid:xxx" 在 SOAP Body 里引用它们。
它解决的核心问题是：**不把二进制数据 Base64 编进 XML 字符串里**——避免体积膨胀约 33%、解析开销大、XML 工具链难处理等问题。
但 SwA 已基本被弃用。下面说清楚怎么用、为什么现在不该用、以及你真正该关心什么。
SwA 的 HTTP 请求长什么样？
关键点是：Content-Type: multipart/related + start 参数指向 SOAP part，每个 part 有独立 Content-ID：
POST /service HTTP/1.1
Content-Type: multipart/related; type="text/xml"; start="<soap.xml>"
Content-Length: ...
--boundary_123
Content-ID: <soap.xml>
Content-Type: text/xml
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<UploadDocument xmlns="http://example.com/">
<file href="cid:report.pdf"/>
</UploadDocument>
</soap:Body>
</soap:Envelope>
--boundary_123
Content-ID: <report.pdf>
Content-Type: application/pdf
%PDF-1.4...（原始 PDF 二进制字节，无编码）
-
start必须匹配第一个 part 的Content-ID（含尖括号） -
href="cid:xxx"中的xxx必须与目标 part 的Content-ID值严格一致（包括尖括号） - 附件内容**不能做 Base64 编码**——这是 SwA 相比纯 XML Base64 的最大优势
- 多数现代 HTTP 客户端（如 Python
requests、Node.jsnode-fetch）默认不生成这种结构，需手动构造 multipart body
为什么 SwA 几乎没人用了？
不是它设计得不好，而是生态和规范演进淘汰了它：
- .NET Framework 2.0+ 完全不支持 SwA，只支持
MTOM；Java Axis2 默认关掉 SwA，需显式启用且易出错 - WSDL 1.1 的
document/literal绑定与 SwA 不兼容——而 document/literal 已成事实标准 - SwA 没定义如何处理多个附件、附件元数据、错误时的附件清理等边界问题，各实现五花八门
- W3C 正式推荐
MTOM（基于 XOP）替代 SwA，它保留了“不 Base64 编码”的核心优势，但通过标准化的xop:Include元素 + 更健壮的 MIME 规则解决了互操作性问题
你今天该用什么？MTOM 还是直接绕过 SOAP？
除非对接遗留系统明确要求 SwA，否则不要主动选它：
- 新服务优先用
MTOM：主流框架（Java CXF/JAX-WS、.NET WCF、Python Zeep）都原生支持，WSDL 可自动生成，Content-Transfer-Encoding: binary+xop:Include更可靠 - 如果只是传文件，考虑放弃 SOAP 全流程：用 REST +
multipart/form-data（如curl -F "file=@report.pdf" https://api.example.com/upload），更轻量、调试直观、工具链成熟 - 若必须用 SwA（比如老 IBM DataPower 或 WebSphere 配置），注意：HTTP 节点需开启 MIME 解析，且不能用通用 XML 解析器直接读 Body——必须先按
multipart/related拆包，再分别处理 XML part 和附件 part
