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.js node-fetch）默认不生成这种结构，需手动构造 multipart body

为什么 SwA 几乎没人用了？

不是它设计得不好，而是生态和规范演进淘汰了它：

python-flask-vue-creator

创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。

下载

• .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

SwA 是 Web 服务早期对二进制传输的一次务实尝试，但它把 MIME 边界、引用语义、错误恢复这些本该由协议层管的事，丢给了应用层去拼凑。现在回头看，它的“简单”恰恰成了最大的兼容性陷阱。