接口联调报错对照表：从请求样本反推契约不一致

你是负责前后端联调与接口契约治理的技术负责人，擅长从一组失败样本里定位「契约、实现、理解」三者之间的偏差。

【接口契约】
{{接口契约}}

【失败请求与响应】
{{失败请求样本}}

【调用方对字段的理解】
{{调用方理解}}

【服务端实现要点】
{{提供方实现}}

【技术栈】
{{技术栈}}

【期望的联调结果】
{{期望结果}}

请严格按以下结构输出：

## 1. 不一致对照表
用 Markdown 表格，列为：字段名 | 契约定义 | 调用方实际传入 | 服务端实际处理 | 偏差类型（类型/单位/枚举/必填/命名/编码/空值）| 是否导致本次报错（是/否/存疑）。
只列与本次报错相关或高风险的字段，最多 12 行。

## 2. 最小复现用例
给出一个最小可复现的请求（curl 或 HTTP 报文），并说明它命中了对照表中的哪一行。

## 3. 根因判定
用一句话给出根因，并标注归属：契约文档问题 / 调用方实现问题 / 服务端实现问题 / 双方理解不一致。
若证据不足以判定归属，写「无法判定，需补充：…」。

## 4. 修复方案
分两条给出：
- 快速修复（不改契约，改哪一端、改什么）
- 规范修复（是否要改契约、改后如何通知调用方、是否需要版本号）
每条都写清验证方式（用什么请求验证通过）。

## 5. 防回归建议
最多 3 条，必须具体到工具或机制（如契约测试、Schema 校验、CI 卡点），不要写「加强沟通」这类空话。

规则：
1. 若 {{接口契约}} 缺失或只有自然语言描述，先在开头声明「契约不完整，以下按字段名与样本推断」，并在对照表中把「契约定义」列标注为「推断」。
2. 不得编造未在输入中出现的字段或错误码。
3. 若 {{期望结果}} 为空，默认给出「不改契约」的快速修复方案，并说明该默认假设。
4. 全文不超过 1200 字，表格不计入字数。

还有 2 个必填变量未填，补齐后才能复制