游客点完提交，屏幕上只有"预约失败"四个字，客服的追问就来了：选的哪个时段、填的哪种证件、什么时候填的，一句都对不上系统里的记录。这三类原因本来发生在一条请求链路的不同位置，被合并成同一个提示之后，用户不知道该改什么，运营也统计不出该改哪处配置。

链路上的先后顺序是：先判库存，再判时段，最后判证件。库存判的是这个票种在这个时段还有没有额度，读的是时段余量字段，失败条件是余量为零或小于本次请求的人头数。这里有个执行顺序上的关键点：库存扣减要放在证件校验之后。先扣后判，证件不通过就得回滚，并发时会出现余量抖动和"明明提示约到、结果失败"的争议；先判后扣，一次请求在锁里算完，代价只是几十毫秒。

时段这一层的三种形态，最容易被一起说成"没票"。一是该时段的售卖窗口已经关闭，余量还在但不再受理；二是所选入园时刻早于当前时刻，这在跨天时会出现，前一天夜里提交、服务端次日零点处理，日期就跳到了前一天；三是提前天数不满足，要求提前一天约的票种在当天提交。三条各有判定字段，提示要能分别说出"改下一个时段""明天再来""走现场窗口"。停售的判定不能信任客户端时间，两端时差先实测，误差超过一分钟就一律以服务端时刻为准。

证件这一层最杂。格式与校验位不对；证件有效期已过或剩余不足；人群类别与票种不匹配，例如儿童票录了成人年龄、优待票没有对应类别；最后是同一证件在这个"证件号加入园日期加时段"的组合上已经被占用。判定唯一性的键就是这三段，少了时段这一段，就会出现同一个人上午约完还能约下午，凭空多占一个名额。这一类被挡回去时如果也只回"提交失败"，用户会以为是没票，反复提交，把库存判定的日志刷满。

错误码建议分三个一级类，下面至少七个二级码：余量不足、余量小于请求人头、该时段已停售、入园时刻已过、提前天数不足、证件校验不通过、该证件当日已约。客服只看一级码就知道让用户改什么，二级码留给后台统计。另有第五种情况不属于这三类：证件核验的外部接口超时、库存服务未响应，必须单独记成一类"待定"，写入日志并允许原单重试一次。把它并进"没票"，会让这个统计量长期虚高，最后连运营自己都不信这个数。

分开之后能做的是按原因回头改配置。证件不通过集中在某一个票种，多半是人群类别与年龄区间配错，不是游客填错；"该时段已停售"的失败量在开园后一小时里最高，说明页面没有把停售时刻和入园截止讲清楚，而不是真的没票；余量不足全落在第一个时段，那是额度分配比例的问题，跟承载量无关。失败量和成功量并排按日出，是判断预约配置准不准最直接的一组证据。