景区票务系统上线检票环节时，最先吵起来的是售检票系统与入口闸机的对接：设备厂家说走它的协议，票务系统说走标准接口，现场最后靠"能刷开就行"过关。能刷开只是第一天，节假日人流一起来，三种事故会依次出现：判定不一致导致同一张票有的通道能进有的不能，失联没有告警导致设备离线两小时无人发现，指令失败没有回执导致游客被拦在门外而系统记成了已核销。这三件事都对应一条必须在对接前谈清的约定。

第一件：判定放在哪一侧。一张票能不能进，判定逻辑应当只有一份，且在景区票务系统一侧。设备只负责三件事：读凭证、发核验请求、按返回结果开闸或拒绝。设备侧本地缓存只承担两种职责——离线兜底和作废名单核对，不能自己长出一套规则。规则分成两处之后会出现典型的现场矛盾：闸机按有效期拒绝，而票务系统按改签后的新日期认为有效，两边各说一句，游客无法判断听谁的。对接时要把字段清单钉死：请求带票号、凭证类型、站点编号、通道编号、设备时间；返回带放行与否、原因码、剩余次数、该次流水号。

第二件：心跳要区分三种状态。设备在线与否不能只看网络通不通。票务管理系统要区分在线（能发核验请求且响应正常）、可达但无核验记录（网络通而当天没有一条流水，通常是采集程序停了）、失联（连续多个心跳周期无响应）。只有两态的系统会出现"后台显示在线、通道其实早就停了"的情况，而这恰恰是排队事故的最大来源。心跳周期要短——三十秒一次，失联超过两个周期就上报到值守看板并记录首次失联时间，事后复盘才有依据。

第三件：开闸指令失败后谁负责。最容易出错的是这一段：票务系统判放行并写了核销流水，闸机却因机械或信号原因没有开闸。游客没有入园，系统已经记了一次核销，报表上入园量虚高，游客手里那张票再也进不去。对接时必须要求设备回一个执行结果，回不来就把这条流水标为待复核，而不是直接计入核销；同时给现场一条补救动作：员工在手持检票机上确认放行，或者按票号作废那条流水并重发一次凭证。景区票务系统的核销口径要不要包含"待复核"，是这一段对接的核心业务问题，不是技术细节。

离线兜底要有边界。失联期间的通行只能按本地缓存判定，兜底必须写清三个限制：只允许本景区票段内的凭证、只允许时段匹配的凭证、名单版本落后超过约定时长就不再允许自动放行而转人工。恢复联网后设备要先上传流水、再拉新作废名单，最后对离线期间的通行记录做一次二次比对，把用了退款票、作废票的通行挑成异常。顺序反了就会出现数据没上传就被新名单覆盖的情况。

验收对接不要只看能不能刷开。拿四种票各刷一次——正常有效票、已核销票、退款作废票、非本景区票；再把设备断网刷一次、恢复后再查一次。这六种结果全部与票务系统的记录一致，售检票系统的对接才算做完。功能演示只测第一条，事故都在后面五条里。