关于系统对接，你可能想知道

先分清是一次性历史补录，还是日常增量同步——几十万行通常出现在首次全量或补历史数据的场景，日常跑增量一般只有几千到几万行，压力小得多。 真遇到大批量，常用五种办法：一是分页分批，按时间或主键切片，每批几千到一万行提交一次，避免单次请求过大导致超时；二是只传增量，用时间戳或版本号做水位线，跑过的不重复传；三是错峰执行，放在夜间或业务低峰，避开月末结账和大促时段；四是目标端批量提交，先落中间表再一次性入库，比逐行写入快一个量级；五是先定位耗时环节，取数慢就优化查询条件与索引，传输慢就压缩合并、减少字段往返，写入慢就减少逐行校验。 经验量级：几十万行走增量模式，通常几十分钟到两三小时可以跑完，具体看字段数量与目标端写入能力。正式上线前我们会用真实数据量做一次压测，确认耗时窗口能放进业务空档，再定执行频率和时间点。

主要四类。第一，接口与口径材料：接口文档或报送模板、字段含义与必填规则、编码规则（货号、网点、客户的编码由谁定义）、退回重报的处理规则。没有接口文档的，至少要拿到模板和样例数据。 第二，测试环境：测试账号、测试接口地址、能覆盖正常与异常场景的样例数据。没有测试环境就只能拿生产数据试，风险高，一般建议先申请。 第三，生产权限：正式接口的账号密钥、访问白名单（我们出口 IP 要加进去）、平台侧的应用授权或开通流程。这一环在品牌方和大型平台内部审批周期较长，往往要一到两周，建议项目一开始就启动申请，不要等联调时才提。 第四，变更与响应机制：模板改版、字段增减、接口升级需提前通知；报送被退回或数据异常时，能找到对口的业务与技术联系人。 实操建议：项目启动时把这些列成一份配合清单，明确每项的责任方和时限，双方确认后按清单推进。多数项目延期，卡点不在开发，而在等权限和等对方确认口径。对方确实无法提供接口的，也可以用模板导出加定时上传的方式兜底，先评估数据量与时效要求。

常规流程基本都能自动化：数据按定时或触发条件同步、格式转换、报送前校验、失败重试，这些不需要人盯。我们在项目里通常把目标定成日常不用管、异常才找人。但有四类情况要留人工接口。一是缺主数据映射：对方来了新货号、新客户、新单位，映射表里没有，程序挂起等确认，这是最常见的介入原因。二是业务规则判断：某张单据该不该上报、某笔退货冲哪一次、某个客户算不算本期返利，要看合同或双方约定，程序不替你拍板。三是审批与责任：报送前要不要签字、金额超了要不要复核，属于内控要求，多数企业选择保留人工确认。四是异常处置：对方系统升级改了字段、断网后补传、双方数据不一致时以谁为准，都要有人跟进。做法是把边界先写清楚：哪些环节自动跑、哪些情况进待办队列、待办由谁在多长时间内处理、超时怎么告警；新增映射、补传、重试、撤销这几个人工动作要留操作入口并记日志。上线初期建议双轨核对，跑稳一两个周期后再逐步缩小人工介入范围。

不会丢，但前提是方案里做好了三件事：本地留痕、失败重试、差异对账。 具体是这样运作的。第一，本地队列：要发出的数据先写进本地待发队列并标记状态（待发送、已发送、失败），只有收到对方明确的成功回执才改成已发送。第二，自动重试：网络中断或对方返回错误时按递增间隔重试，比如 1 分钟、5 分钟、30 分钟各试一次。第三，死信与告警：重试仍失败的进入死信队列，同时发出告警，不会静默失败。第四，断点重放：对方恢复后按队列重新发送，并用业务单据号做幂等去重，同一张单重复提交不会在对方系统里生成两张。第五，人工兜底：保留手动重发入口和人工补录通道，遇到对方接口变更这类必须改程序的情况，先把数据留在本地，改完再补传。 还有两个容易忽略的点：断网期间本地业务照常开单，恢复后批量补传，业务不用停；走文件交换方式的，文件先落本地目录，按时间戳顺序补传。另外不要只依赖告警，建议每天跑一次差异对账，比对本地已生成数量与对方已接收数量，有差额及时查。上线前我们会把断网恢复演练一遍，确认这套机制真的能用。

不建议边清理边对接。顺序通常是先体检、再清理、后上线，也不必等到数据完全干净才启动项目。原因是：对接是按规则把一个系统的数搬到另一个系统，规则依赖稳定口径。如果货品编码、客户名称、计量单位还在改，映射表就得跟着改，今天对上的数明天又对不上，上线后会一直返工。 一般分三步。第一步，数据体检（一到两周）：导出要对接的货品档案、客户档案、往来余额、库存数量，统计重复编码、空字段、停用未标记、负库存、往来与总账不符的比例，出一份问题清单，看清问题集中在哪些字段。第二步，集中清理（两到四周）：重复编码合并并保留对照、缺失字段补齐、停用货品打标记、负库存查明原因；这一步可与方案设计并行，不额外占工期。第三步，边运行边巩固：上线后开每日对账与异常清单，新问题当天发现当天改，同时定好新增货品、客户的录入规范，防止复发。 有个例外：问题只集中在少数字段（比如只差品牌方货号对照），可以先把这部分清完就启动对接，其余运行中补。判断标准是看这个字段会不会影响映射规则——影响规则的必须先清，不影响的可以后补。

范围靠两份清单界定：一份字段映射表，写清从哪个系统的哪个字段取数、映射到目标系统的哪个字段、口径怎么算（含税不含税、取数日期）；一份流程清单，写清涉及哪几类单据、每类单据的触发条件和回写动作。两份清单确认后就是本次项目的边界，清单内按原报价做，清单外另议。 中途变更确实会发生，我们按三类处理。第一类是不影响结构的微调，比如多传一个已有字段、调整排序或筛选条件，直接做，不加费用。第二类是清单内但实现路径变了，比如对方接口换了版本、字段含义调整，工作量变化不大，由我们承担。第三类是范围新增，比如新接一个系统或新增一类单据，这类先出补充清单，写清工作量、价格和工期，你确认后再做，不会做完才报价。 少踩坑有两个办法：一是需求诊断阶段把单据类型、样本数据和对方接口文档摆出来一起过一遍，很多没想到的需求在这一步就能暴露；二是方案确认时把这次不做的部分也写清楚，避免双方理解不一致。 上线后头一个月允许一轮小调整，属于项目内优化，不计入变更。变更无论大小都走书面确认，改了什么、影响哪些单据都有记录。

诊断阶段需要四类资料。一是系统清单：涉及哪几套系统、名称版本、部署方式、有无接口文档、数据库能否开只读账号。二是账号与权限：各系统测试账号、接口密钥、平台侧开发者授权由谁申请、多久能下来——这一项常是工期的实际瓶颈。三是业务口径：哪几类单据、从哪个系统流向哪个系统、触发条件（下单、付款、发货还是审核完成）、取数含税否、时间按下单日还是发货日、重复数据怎么去重。四是样本与历史数据：真实样本十到三十条，含正常单、退货、部分退款、作废、拆单几类异常，再附近一到三个月数据用于对账。对品牌方或平台报送的，还要给对方的报送规范、字段模板与截止时间。 推进顺序：先按清单自检，缺的列明由谁补、什么时候补；再用样本数据做一次字段映射演练，把源字段、目标字段、换算口径逐行写出来，这一步常能暴露一半没说清的口径问题；然后确认测试环境与上线切换窗口，选业务量小的时段切；资料齐了再出方案与报价，避免中途加需求反复改价。 两个提醒：资料不齐也能启动，但工期与报价会带假设条件，补齐后要重新确认；数据库尽量开只读账号并限定来源 IP。

常见的是四种。一是 API 接口：双方按接口文档传数据，实时性好、字段规范、改动可控，前提是对方愿意开放接口并给测试环境，商城和平台类对接多走这条。二是数据库直连或中间库：直接读写对方库，或约定一个中间库，一方写、一方取；开发快、不受接口限制，缺点是依赖表结构，对方一升级就可能失效，安全上通常只开只读账号并限定来源 IP。三是文件交换：按约定格式（Excel、CSV、TXT）定时放到指定目录或 FTP，简单、稳定、好排查，时效一般按小时或按天，品牌方报送、银行流水导入多用这种。四是消息推送与队列：数据变化即推送，适合同步频率高、有明显峰值的业务，常配合前三种做削峰。 怎么选看四件事：时效要求（分钟级还是按天）、对方开放程度（有没有接口）、数据量与峰值、你们自己的运维能力。经验是有接口优先用接口；对方不开放就退一步用中间库加前置机；只是定期报送的用文件交换最省心；订单量大且集中的用队列削峰。不要一上来就选最复杂的：能用定时文件解决的就不必上实时接口，省下的开发与维护量都是成本。

上线之后通常分三层来维护。第一层是日常巡检与告警，由实施方盯着：接口心跳、任务执行结果、失败队列、数据量突降或突增。异常按级别推送到微信或邮件，不用你派人天天盯后台。第二层是业务侧变更，比如新增字段、调整映射、接一个新的单据类型，走变更流程，先出影响评估再排期。第三层是你们自己的日常操作，比如异常单据补录、映射缺失补齐，培训给对接人，日常不用等我们。 响应建议按问题分级约定，别只写一句「尽快响应」：阻断类（订单不流转、报送整体失败）优先处理，先给止损方案再查根因；数据异常类（个别单据错了、金额对不上）当天定位、次日给纠正方案；咨询与优化类排进常规迭代。响应时限、联系人和升级路径写进运维约定，避免出事时互相等。 三个配套动作建议一并做掉：一是留一份运维文档，写清接口清单、账号与权限归属、常见异常的处理办法，谁接手都能看懂；二是保留切换期的对账报表，出问题时能快速定位是哪一天、哪一类单据开始不对；三是对方系统升级或换版本时提前通知实施方，做一次回归验证再放行——接口失效多数发生在对方升级之后。

数据准不准不能靠感觉，要留三道核对。 第一道是上线前的样例比对。联调阶段挑二三十张有代表性的单据——正常单、退货单、部分退款、多仓出库的都要有，两边逐字段对：笔数、金额、数量、日期、编码、客户。这一步发现的多是映射错误和口径差异（含税不含税、时点不同），此时改成本最低。 第二道是上线后的对账报表。每天自动跑一次，按天、按单据类型统计双方的笔数与金额合计，差值超过阈值就告警。对账报表不是给人天天看的，而是让异常自己冒出来。 第三道是双轨运行。上线头两到四周，接口跑的同时保留原手工流程，每天抽十几张单做人机比对，两边一致再停手工。这段时间的差异要记进台账，写清原因、影响范围和纠正办法。 还要区分两类差异：口径差异按下单时间还是出库时间、含税还是不含税，统一口径即可；真错如编码映射错、重复推送、漏单，要回查日志并重跑。 稳定后降频：首月每天核对，次月起每周抽查，之后每月一轮，同时保留回执与日志，出问题时能定位到哪一天、哪一类单据开始不对。