销售易与金蝶联调一日：Postman 各自都通了，现场还是一地字段

今天公司在做销售易与金蝶的数据互联互通，API 联调。

会前的约定很清晰：双方各自对着接口文档，用 Postman 把己方接口跑通；到现场只做「合龙」——你调我、我调你，把链路串起来，尽量当天看见数据落地。

听起来合理，也符合这些年做集成的惯例：先单测，后联调；先证明「我能发、你能收」，再谈业务是否闭环。

各自都通了，合在一起却不对

事实是，上午各自演示时，两边都说：按文档，Postman 已通过。

到了下午现场一对，问题却像从桌底涌出来：

• 字段类型对不上：文档写字符串，实际要数字；日期有时是时间戳，有时是 yyyy-MM-dd，有时还带时区尾巴。
• 枚举值各说各话：CRM 里叫「已签约」，ERP 要的是另一套编码，中间没人翻译。
• 金额、数量精度不一致：一位小数还是两位，四舍五入规则不同，汇总就对不上。
• 必填与可空：文档标可选，对方校验却拦死；多传一个空字符串，整单报错。
• 主键与关联：销售易的商机 ID 和金蝶的客户档案，映射表临时才发现缺了几条历史数据。

Postman 里一次成功的 200，往往只证明「HTTP 通了」，不证明「业务语义通了」。各自在自己环境里造一条理想数据，很容易皆大欢喜；两边真数据一碰，裂缝就露出来。

为什么没有捷径

这类场面我见多了，但每次还是会提醒自己：集成这件事，从来不奖励侥幸。

文档是滞后的，环境是有差别的，人的理解是有偏差的。你省下的「先把字段表对死」的半天，通常会在联调现场加倍讨回来。想靠「文档写了就行」「Postman 过了就算」跳过去，最后往往多熬一整夜，还多背一口闷气。

没什么捷径，就是成本账。认真对字段，是在买后面的安静；坚持追一条脏数据，是在避免上线后财务来敲门；肯把日志摊开给人看，是在省下互相猜的心力。

今天一行一行对映射、改类型、补字典、重放请求，枯燥，也慢。可每修掉一个问题，链路就实在一分。傍晚再跑一单，销售易里刚变的客户，金蝶里能查到了——那种踏实，Postman 绿灯给不了。

写在后面

联调结束走出会议室，天已经暗了。没有戏剧性，没有人举杯，只有群里多了一句「今晚先这样，明天继续」。

我反而觉得这样挺好。做技术的人，很多时候就是在白板前、日志里、Postman 的 History 旁边，把「差不多」磨成「确实如此」。

销售易和金蝶只是两家系统，背后是两套历史、两种命名习惯，要通过几条 API 对接起来。对接得越像真的，越不能偷懒。明天继续。