复盘一个系统对接项目。客户是一家零售连锁，门店收银系统用了五年（供应商还在，但文档不全），线上商城是新建的。痛点：会员两头各一套，积分对不上；商品改价两边手动改，一天忙到晚。需求很清晰：让两套系统握手。

老系统没文档怎么办

难点一上来就出现：收银系统的接口文档缺失，供应商只能给个接口清单。处理办法：先和供应商确认可开放的能力边界，再做接口探测——逐个接口发测试请求，验证参数和返回，把实际行为记录成文档。这个逆向梳理花了三天，比预想顺利，原因是收银系统虽然文档烂，接口本身还算规范。经验：老系统对接，第一步永远是确认接口能力清单，别拿文档缺失当理由直接放弃。

对接方案与设计取舍

方案定了三条原则：一是商品和价格以收银系统为准，单向推送到商城——价签对不上是零售的大忌，源头唯一；二是会员积分双向同步，以时间戳判定新旧，冲突时以收银系统为准；三是订单从商城推回收银，店员在熟悉的后台看到全部订单。所有接口带重试和日志：某次推送失败，系统自动重试三次并告警，绝不静默丢数据。开发四周，联调一周。

数据怎么对才放心

上线前的验收关键在对账：一个月的历史数据回灌模拟跑：商品价格逐条对，会员积分抽样一百个核对，订单推回全量验证。发现一个积分同步的边界bug（客人同一天在两头各消费一次），修复后重跑，全绿才切正式。上线后并行观察两周：两套系统的积分报表每天核对，一致了才关掉旧的手工改价流程。数据对接的信心是核出来的，不是开发说没问题就没问题。

给池州企业的启示

系统对接项目的三条经验：接口能力先探测确认，文档缺失不是死路；数据源头要唯一，两边都说了算迟早打架；上线必须并行对账，对齐了才切换。池州信服无限做对接项目，逆向梳理和对账验证都是标准动作，交付含接口文档——以后换团队，新的接手人不用再考古。

总结：对接不难，难在把数据理顺

两套系统握手，技术上是接口，功夫在数据源头唯一和对账验证。握手谈好了，会员和价格从此一张脸。

系统对接的常见疑问

没文档能对接吗？

能，接口探测逆向梳理，先确认能力边界。

数据冲突怎么办？

源头唯一加时间戳判定，规则前置定好。

对接要多久？

这个规模五周，视系统新旧浮动。