景区票务系统里把演出票、索道票和游船票都做成场次票，看着是同一件事，实际三处配置的侧重完全不同：演出在乎开场时刻与迟到怎么放行，索道是循环发班、在乎的是排队与单位时间运力，游船在乎开航窗口与定员。用一套场次模板套三种业务，末班船和最后一场演出都会出问题。

一、场次时刻表有两种形态。固定时刻型适用于演出和游船，每场有明确的开始与预计结束时刻；循环发班型适用于索道，没有结束时刻，只有发班间隔与运行时段。字段上要么给出间隔，要么给出时刻，不能两个都留空由现场自行判断。

二、每场容量是配出来的，不是抄座位数。容量来源可能是定员、舱位数、摆渡能力或船定员。真正能售的数要在来源数上扣掉三类预留：团队预留、免票与补录预留、现场应急预留。扣完之后的数进售罄判定。预留不落字段，就会出现窗口现场说还有票、闸机端已经放不下的情况。

三、停止入场时间不能一个字面值三种含义。演出常见的是开场后若干分钟内仍可入场，之后彻底停检；索道按循环班，只关心当下是否在运行时段；游船往往在开航前若干分钟就停止放行，因为要结算定员。建议拆成三个字段：最早可入场时刻、最晚可入场时刻、场次关闭时刻，配置时逐场填。

四、判定顺序要固定。核验一条请求时，先确认票的场次归属，再看该场当前状态（未开、在售、停止入场、已结束、已取消），再看本场剩余容量，最后看票自身状态。顺序反了会出现"改签到一场已停检的场次"和"停场之后仍被放行"两种事故。

五、改签与售罄的连带动作。改签目标场次必须同时满足同票种、有余量、尚未过最晚入场时刻，三个条件缺一即拒，且改签保留原场次记录。本场余量为零时的等待队列应当走线上取号，不占用闸机通道的核验请求。超售只在索道这类循环班次上小比例使用，演出与游船按定员硬约束处理。

六、设备端要知道票属于哪场。核验请求带票号与场次号，服务端返回放行与否、场次归属、最晚入场时刻与本场余量。设备不能自己推断"现在就是这一场"，索道这类循环班次还要额外返回下一班提示。

七、临时停场的处置路径。大风停航、设备检修时，景区票务系统要按场次批量把该场未核销票置为停场状态，生成应退清单并等运营确认后进入退款，同时把停场场次下发到设备端。闸机与手持检票机如果只靠本地缓存判断，就会出现停场之后照样开闸的场面，事后既没法定位人数也没法解释退款范围。

常见的现场状况：末班船提前停检，几十人排到最后进不去又没人解释规则；演出迟到观众被判过期，而票务系统里那张票其实仍在迟到放行窗口内。两处都是配置字段不够直白导致的。

验收按四个节点各刷一次：开售、售罄、停检、取消。四种结果在闸机、窗口终端和手持检票机上返回一致，且售罄与取消都不产生新的核销流水，场次票的配置才算闭环。