老系统没有API接口怎么对接：三条改造路径的成本与取舍
老系统没有 API，对接只有三条路：读它的数据库做中间表、用界面自动化模拟人工录入、在原系统上二次开发开出接口。三者成本差三到十倍，判断依据是数据要不要实时、能不能改动原系统、以及这套系统还打算用几年。
一、先分清你要的到底是哪件事
很多被叫作“对接”的需求，实际是三种不同的东西。第一步分错，后面全是返工。
- 数据搬运：A 系统里的单据要出现在 B 系统里，晚半小时没关系。
- 业务联动：B 系统下单要实时占用 A 系统的库存，不允许超卖。
- 界面统一：两个系统各干各的，只是想让员工在一个页面里操作。
第一种适合做中间表，第二种必须走接口，第三种往往是单点登录或者门户，跟接口改造根本不是一回事。先把这三类分开，再谈技术选型，能省掉一半的返工。
二、路径一：读数据库做中间表
做法：用只读账号连上对方数据库，建视图或定时任务，把有变化的数据落到中间表，己方系统按周期读取。
适合的情况：数据滞后可以接受，五分钟到一小时都行的；对方是自建机房，或者至少愿意开只读账号；表结构稳定，三年内不换系统。
成本：单条数据流一般 3 到 10 人日。
代价：这条路绕过了对方的业务逻辑。对方系统里“审核”这一步会写状态字段、扣减库存、生成流水，你直接读表只拿到状态值，业务含义靠猜。对方一升级改表，字段名就对不上，同步会静默断掉。
必须配套：增量字段（updated_at 或自增 id）、字段映射表、每日对账。三样缺一不可，尤其是对账。中间表最容易出的问题不是同步失败，是同步成功但业务口径不一致，账面看着有数，实际对不上。
三、路径二：界面自动化模拟录入
做法：用脚本或 RPA 驱动键鼠，走对方系统的界面完成录入和查询。
适合的情况：厂商彻底封闭，很多老 ERP、老财务软件就是这种；数据量小，每天几十到几百条；只是过渡，不指望用三年。
成本：单个流程 2 到 5 人日。
代价：极其脆弱。分辨率变了、弹窗顺序换了、版本小升级、输入法切到中文，都可能让流程挂掉。而且在对方系统里，这些操作和人手录入留下的痕迹一样，出了差错分不清是谁的责任。
必须配套：失败告警，不能静默重试；幂等校验，防止一次重跑变成两条单据；全程录屏留证，出问题能倒查。
四、路径三：在原系统上二次开发开接口
做法：在原系统里按厂商提供的 SDK、插件机制或存储过程，暴露一组 HTTP 接口，按标准的请求和响应格式对外提供服务。
适合的情况：长期使用、高频调用、要求实时、需要审计留痕。
成本：15 到 60 人日，取决于原系统的开放程度。
代价：最贵，也最依赖厂商配合。不少老系统厂商不愿意开放底层，或者开放要另收接口授权费。原系统升级时你的改造还可能被覆盖，合同里必须写清维护责任和升级兼容义务。
必须配套：接口文档、鉴权、限流、幂等、版本兼容策略。这五项在软件接口设计怎么做里逐条展开过，这里不重复。
五、三条路径怎么选：一张对照表
| 维度 | 数据库中间表 | 界面自动化 | 二次开发开接口 |
|---|---|---|---|
| 实时性 | 分钟到小时级 | 分钟级，串行执行 | 秒级 |
| 是否改动原系统 | 否 | 否 | 是 |
| 单条流成本 | 3 到 10 人日 | 2 到 5 人日每流程 | 15 到 60 人日 |
| 上线速度 | 快 | 快 | 慢 |
| 稳定性 | 中，怕改表 | 低，怕界面变 | 高 |
| 数据一致性 | 靠每日对账兜底 | 靠幂等校验兜底 | 事务内保证 |
| 适合规模 | 中小数据量、事后同步 | 小数据量、低频 | 核心链路、长期使用 |
如果只想要一句判断：只是出报表、月底对一次数，走中间表；厂商死活不开、每天就几百单，走界面自动化；这条链路停了业务就停，必须做二次开发。
六、不管走哪条路，这五件事必须先定
- 状态字段的语义对齐。对方系统里 0、1、2 分别表示什么，和你系统里的 0、1、2 是不是一回事，要逐条对完再动手。这一步错了，后面所有数据都是错的，而且错得很安静。
- 时区和日期格式。老系统的 datetime 常常是本地时间、不带时区；新系统按 ISO8601 存 UTC，一进一出就差八小时。跨年、跨月的单据会因此落错账期。
- 编码。GBK 的老库接到 UTF-8 的新系统，中文变问号是常事。一定要在测试环境用真实的中文客户名和商品名跑一遍，别用 test001 这种数据自欺欺人。
- 幂等。同一条单据重跑一次不能变成两条，否则财务对账永远对不平。用业务单号做唯一键是最简单可靠的办法。
- 对账机制。每天跑一次总量和金额的比对，差异超过阈值就告警。没有对账的对接，错误往往三个月后才被发现，那时候已经很难往回追了。
七、什么时候不该对接，该换系统
判断标准很朴素：把三条路径里最便宜那条的改造成本，和这套系统还能创造的价值比一比。
如果原系统厂商已经停止维护、找不到人配合、连表结构文档都没有，改造预算做到 40 人日以上，而系统本身还在跑十年前的业务逻辑——这时候投产比是负的，换系统比对接便宜，而且一劳永逸。
反过来，如果原系统承载着核心业务数据、换系统要停机一周以上，那就老老实实做接口，哪怕贵。停机一周的损失，通常比 60 人日贵得多。
常见问题
问：老系统只肯给导出 Excel，这算接口吗？
不算。Excel 导出是人工触发、无法定时的。但如果你能用脚本定时登录后台下载、再解析入库，本质上是路径二的变体，稳定性比逐条界面录入好一些，适合当过渡方案。
问：厂商说要收接口授权费，合理吗？
行业里常见，尤其国外 ERP。先确认是一次性收费还是按年收，以及是否包含后续版本升级。按年收费且金额高的，往往不如走中间表划算。
问：对接做完多久算稳定？
中间表方案一般要跑满一个月、跨过一次月末结账；接口方案跑满两周、跨过一次业务高峰。没跨过这两个节点的，都只能算联调通过。
问：三条路可以混着用吗？
可以，而且经常是最优解。核心链路（下单、扣库存）做接口，报表类数据走中间表，边缘的老系统用界面自动化兜底。分层处理，预算才能花在刀刃上。多系统怎么分层打通，可以参考多系统数据打通怎么做。
小结
接口改造没有标准答案，只有和你的系统寿命、预算、业务节奏匹配的答案。先判断数据要不要实时，再判断原系统还能活几年，最后才轮到选技术。
厦门经纬度软件做 API 接口开发，RESTful、SOAP、GraphQL 都做过，也接得动没有接口的老系统。改造方案怎么定，可以先聊半小时。
咨询热线：0592-8061158 邮箱：32518962@qq.com 地址：厦门市软件园三期集美北大道1140号