MTOM是SOAP上传附件的唯一标准方案，它将二进制附件分离为独立MIME part，XML仅保留xop:Include引用；需WSDL声明mtom="true"、客户端服务端均启用MTOM并配置对应拦截器或编码方式，缺一不可。
SOAP 上传附件时，MTOM 是唯一靠谱的选择
不用 MTOM，硬塞二进制进 XML 字符串（比如 base64），基本等于自找麻烦：体积膨胀约 33%，解析慢，内存爆得快，服务端还可能直接拒收超长 text 节点。SOAP 协议本身不传文件，MTOM（Message Transmission Optimization Mechanism）才是 W3C 标准里专门干这事的机制——它把附件抽成独立的二进制 part，XML 只留个 xop:Include 引用。
实操建议：
- 客户端和服务端必须同时启用
MTOM，光一端开没用；检查 WSDL 里有没有mtom="true"或type="application/xop+xml" - Java Axis2 / CXF 默认关 MTOM，得显式设
binding.setMTOMEnabled(true)；.NET 的BasicHttpBinding要配messageEncoding="Mtom" - 别手动拼
multipart/related请求体——所有主流 SOAP 库（如 Python 的zeep、Java 的jaxws-ri）都内置 MTOM 支持，调用时传bytes或File对象即可，库自动拆包
Attachment 在 SOAP 消息里根本不存在
这是最常被文档带偏的点：WSDL 和 SOAP 规范里压根没有叫 Attachment 的元素或类型。所谓“附件”，只是 MTOM 封装后 HTTP body 里的一个独立 MIME part，XML 正文里只出现类似这样的占位符：<include href="cid:12345@apache.org"></include>。如果你在 XML 中硬加了个 <attachment>...</attachment> 节点，那只是普通字符串字段，不是附件。
常见错误现象：
- 服务端收到的是 base64 编码的长字符串，而不是原始文件流
- 用 Wireshark 抓包发现 HTTP body 是纯文本 XML，没看到
multipart/relatedboundary - WSDL 中
xs:base64Binary类型字段被当成普通参数传，实际走的是 XML 内联编码，不是 MTOM
Python zeep 传文件必须用 requests 会话 + MTOM 绑定
zeep 默认用 httpx，但 MTOM 支持依赖底层 HTTP client 对 multipart 的正确构造。requests 更稳，且需手动指定传输绑定。
实操建议：
- 创建 client 时传
transport=Transport(session=requests.Session()) - 确保 WSDL 地址返回的 binding 包含
mtom="true"，否则 zeep 会 fallback 到文本模式 - 调用方法时，附件字段直接传
open("file.pdf", "rb").read()或io.BytesIO(data)，别转成 base64 字符串 - 如果报错
ValueError: Cannot serialize bytes object，说明 zeep 没识别出 MTOM，回头检查 WSDL 或强制指定plugins=[WsdlPlugin()]
Java CXF 客户端收不到附件？先看 AttachmentInInterceptor 是否注册
CXF 默认不解析入站的 MTOM part，需要显式加拦截器，否则 javax.activation.DataHandler 字段永远是 null。
关键配置点：
- 客户端代码里加：
client.getOutInterceptors().add(new org.apache.cxf.interceptor.AttachmentOutInterceptor()); - 服务端对应要加：
server.getInInterceptors().add(new org.apache.cxf.interceptor.AttachmentInInterceptor()); - 如果用 Spring 配置，确认
cxf.xml里有<bean class="org.apache.cxf.interceptor.AttachmentInInterceptor"></bean> - 调试时打印
message.getAttachments()，为空就说明拦截器没生效，跟 WSDL 或 binding 无关
