对接出问题，十次有八次不是接口不通，而是两边对同一句话的理解不同：库存以谁为准、核销算哪一刻、超时了要不要重试、字段对不上谁改。这些口径应该在开发之前写进一份双方确认的文档，而不是在联调群里聊定。下面四类最常起争议。

库存只能有一个权威

票务服务端是库存的唯一出口，设备侧和渠道侧都只发请求，不各自记账。只要允许某一方留本地可售数做兜底扣减，超卖就会出现在两边都以为还剩最后一张的那一刻。要定的是三件事：扣减发生在哪一步，下单、支付成功还是出票完成，三个时点结果完全不同；未支付订单多久回滚；某时段售罄之后要不要开放候补。真要离线兜底，只兜放行不兜库存——本地保留已授权凭证的名单，不再新增可售数量。争议发生后按什么判？看扣减流水号。每个请求带订单号和唯一流水号，服务端保留处理顺序，谁先扣成功一目了然。

核销回传的三种时机

第一种设备本地先放行、事后异步回传，网络差也能用，代价是状态延迟。第二种服务端校验通过才放行，状态最准，但对链路质量要求高。第三种是预下发名单的离线模式，开园前把可核销凭证推到通道设备端。三档的字段和对账口径不一样，不要混着上线。最小回传字段要谈拢：凭证唯一标识、设备序列号、通道号、进出方向、时间戳、结果码，结果码至少要区分成功、重复、无效、超时，人工补录时还要带操作员。少一个字段，事后就解释不清这一条是谁放的。

超时不等于失败，重复请求要有幂等键

设备发出核销请求却没收到响应，它只有两个选择：重试，或者判失败。重试可能造成重复记录，判失败可能让已经进去的人被记成没进。办法是请求自带幂等键，同一凭证、同一通道、同一请求号重复提交时，服务端返回首次结果而不重复扣减。重试次数与间隔要约定，服务端保留响应缓存，对账按流水号去重。这些在设计阶段定好很容易，事后补脚本非常痛苦。退款凭证走同一条链路：状态变更要能推到设备端，推不到的窗口期有多长，双方实测一个数字写进文档，现场据此决定要不要人工复核。

主数据由票务侧定义并版本化

票种编码、场次标识、人群类别这些主数据，应由票务系统定义、以编码下发，对方按编码回传。让渠道直接传中文票种名是最常见也最容易出事的写法：改一个字，两边统计就分家。字段要改时给版本号和一段并行期，并约定回滚条件；新字段先在一两个通道灰度，跑稳再全量。联调顺序建议固定：先拉基础数据，再走下单与查询，然后核销，最后对账，前一步没通不要抢着试下一步。

接口之外的一条

把异常用例列进验收单：重复请求、响应超时、退后再刷、跨场次核销、离线名单过期。这几条能过，剩下的问题都出得慢。系统按微服务拆分、接口层独立部署的项目，遇到对方改字段不至于拖着整条链路重发版，后面要加一个新渠道也不用整站重来。