SOAP请求必须严格遵循WSDL契约，包括命名空间、元素顺序、空值表示等；推荐用Zeep或JAX-WS生成客户端代码，调试需抓取原始HTTP流量逐字比对。
SOAP请求体必须严格匹配WSDL定义的soap:Body结构
WSDL文件里的message和portType决定了XML请求的根元素名、命名空间和子元素顺序。手写请求时，哪怕xmlns少一个冒号、xs:element声明的minOccurs="0"字段被意外包含，服务端都可能直接返回SOAP-ENV:Client错误。
- 用
wsdl2py（Zeep）或wsimport（JAX-WS）生成客户端代码，比手动拼XML更可靠 - 检查WSDL中
<binding></binding>下的style="document"还是style="rpc"：前者要求soap:Body内直接是操作名元素，后者会多一层封装 - 命名空间前缀（如
tns:、ns1:）必须与WSDL中<definitions xmlns:...></definitions>声明一致，不能仅靠默认命名空间“省略”
响应XML解析失败常因命名空间或类型映射不一致
服务端返回的soap:Body里，元素可能带xmlns=""清空默认命名空间，或用xsi:type指定具体类型（如xsi:type="xsd:string"），而客户端解析器若忽略这些，就会把值读成None或报ElementTree.ParseError。
- Python用
lxml.etree时，显式传入namespaces参数，例如root.find('.//{http://example.com}Result', ns) - Java Axis2默认不校验
xsi:type，但启用schemaValidation=true后会因类型不匹配抛AxisFault - 响应中
SOAP-ENV:Fault的faultcode值（如Server或Client）比HTTP状态码更能定位问题根源
Zeep Python库自动处理命名空间但需注意strict=False的副作用
Zeep默认开启严格模式（strict=True），遇到WSDL未声明的字段或额外属性就报TypeError；设为False虽能跳过校验，但可能导致result对象缺失关键字段——尤其当服务端返回了可选元素却没在WSDL中标记minOccurs="0"时。
from zeep import Client
client = Client('service.wsdl', strict=False) # 关键开关
# 调用后检查 result._value_1 是否存在，而非直接访问 result.field_name
response = client.service.GetUserInfo(id=123)
if hasattr(response, '_value_1'):
data = response._value_1
else:
data = response
- 用
client.wsdl.dump()确认Zeep实际识别的输入/输出消息结构 - 对含
anyType或any的WSDL，Zeep返回的是object而非dict，需用zeep.helpers.serialize_object()转成标准Python类型 - 避免在生产环境长期使用
strict=False，它掩盖了WSDL与实际服务的偏差
调试SOAP流量必须捕获原始HTTP请求/响应而非日志摘要
很多框架（如Spring Web Services）的日志只打印“marshalled request”，省略了Content-Type: text/xml; charset=utf-8头、SOAPAction头，甚至整个soap:Envelope外层。真正出错时，问题往往藏在这些地方。
- 用
mitmproxy或Fiddler抓包，确认POST /Service.asmx的请求体是否含BOM、换行符是否为\r\n（某些老ASMX服务拒收\n） - 响应中的
Content-Encoding: gzip头若未被客户端解压，会导致XML解析失败，错误信息常为“unclosed token” - WSDL地址本身带
?wsdl参数时，注意有些服务要求?WSDL（大写）才返回正确内容
WSDL不是文档而是契约，XML节点名、命名空间、顺序、空值表示法（nil="true"还是省略元素）任何一项不一致，都会让请求在传输层之下就失败。别信“差不多能通”，得逐字比对。
