小程序对接已有系统：接口、账号与数据归属先理清
一行需求背后可能藏着几周工作
小程序的功能清单里常有一句“对接现有会员系统”或“同步库存数据”。写在文档里只有几个字，落到开发上可能牵出账号申请、接口改造、网络打通、数据清洗一连串事情。这些工作本身不算难，难在发现得晚——做到订单页才发现接口只在内网可用，排期只能往后推。
对接能不能做、要花多久，在报价之前就该有结论。
接口先看三个问题
- 现有系统有没有对外接口。自研系统要看当初有没有预留接口层，采购的软件要看厂商是否提供开放平台，SaaS产品通常有API但权限分级。三种情况的工作量差别很大。
- 接口是只读还是可写。读取商品、库存、会员信息属于低风险；下单、扣减库存、修改订单状态属于写操作，要额外考虑重复提交和并发冲突怎么处理。
- 要不要改对方系统。如果需要厂商新开接口，工期就不再由小程序团队单方面决定，得排进对方的技术支持排期，这一项经常被漏掉。
还有一个容易忽略的点：网络。企业系统部署在内网的情况很常见，小程序运行在用户手机上，必须经公网访问。中间加不加网关、由谁维护、出问题找谁，这些要在方案阶段说清楚，而不是等联调时才发现连不上。
账号和权限，重点在测试环境
正式环境的账号一般好解决，企业方开一个受限账号即可。真正拖时间的是测试环境：没有独立测试数据，开发只能碰正式数据，企业方通常不会同意；于是要么等，要么绕。比较实际的做法是提前准备一套脱敏数据，或者约定测试期内开放受限账号，项目验收后回收。
权限粒度也值得提前定。一个“能读订单”的账号，是全量可见还是按门店、按区域过滤，直接影响接口设计和测试用例。这类细节在开发前确认一次，比上线前临时加判断条件省事。
数据归谁，怎么退出
对接意味着数据在两个系统之间流动。哪一方是数据的责任主体，用户在小程序里产生的行为数据归谁使用，项目终止或更换服务商时数据怎么导出，这些问题在合同阶段谈比在纠纷阶段谈容易得多。
- 明确数据流向：只从企业系统读，还是也会写回。
- 明确留存范围：小程序侧是否缓存用户信息，缓存多久。
- 明确退出方式：接口账号如何停用，历史数据以什么格式交付。
有些情况不适合直接对接
如果现有系统版本老旧、没有接口文档、原厂商已不再维护，强行对接的维护成本可能高于重建一小块业务模块。另一种情况是业务流程本身还没稳定，今天改一次规则、明天改一次字段，这时候更适合先在小程序侧做轻量实现，等规则定下来再打通。
对接的价值在于减少重复录入和口径不一致。如果为了对接让两边都被绑死，每次小改动都要两边同时发版，就失去了意义。
开工前的确认顺序
- 列出小程序需要读写的具体数据项，精确到字段。
- 确认每一项由哪个系统提供，有没有现成接口。
- 确认测试环境的访问方式和数据来源。
- 确认网络方案，以及故障时的责任方。
- 把以上结论写进需求文档，作为工期和报价的依据。
这五步做完，对接部分的不确定性基本能收敛到一个可评估的范围，剩下的才是开发本身。