接监管平台这件事，多数景区卡在同两个地方：对接完就把上报当后台任务不再管；到被抽查那天，才发现报上去的数和自己报表上的数互相解释不了。字段口径、发送频率、失败处理、留痕方式，这四件事都得有人负责到底。

通常要报的四类数据，各算各的

第一类实名预约量，按预约日期和时段汇总，是否按证件去重要提前确认——代全家下单时一个手机会有几条记录，不去重会偏高。第二类瞬时客流，即在园人数，靠进出两侧核销相减；有其他计数点位时，要写清哪些计入、怎么加权。第三类最大承载量对照，即当日核定上限与实时占比，通常要求先把上限值同步上去，调整要有生效日期。第四类票种销售，按票种和渠道汇总，注意退款体现为"减少售出"还是"另记退款"。对接时把这四类的字段名、统计时点、单位、是否包含免票人群逐条写进确认单。

频率、失败重试与补报

瞬时客流一般是分钟级发送，日汇总按自然日切点。发送要有重试：失败进队列、按间隔逐步重试、超过一定次数转人工告警，不能静默丢掉。补报要能指定业务日期，并带上原始业务时间戳——用发送时间补报，平台侧的时段曲线会被整体推后。日切的两处口径要提前定：切点那一刻的在园人数算昨天还是今天，跨日未核销完的订单归哪天，改就要有生效日期和通知记录。定了就别随意改，改就要有生效日期和通知记录。

口径不一致时怎么做对齐

三个来源放一起最容易定位问题：业务系统报表、实际发出的报文、平台返回的接收结果。挑一天做三方对照表。差异最常出现在四处：免票人群和工作人员进出算不算客流；退票在票种销售里怎么体现；团队名单已入园但没逐人核销的算不算已预约；线下出票与线上订单是否归到同一统计维度。找到原因后形成一页口径说明，写清这个数怎么算、包含谁、不包含谁，双方确认后固定。

脱敏与最小化上报

原则是平台没要求的不报，能摘要的不传明文。姓名、手机号、完整证件号通常不需要进上报包；确实要带证件的，按对方要求处理，比如掩码或不可逆转换，规则写进对接文档。另一头要防的是自己：上报日志别留整包明文，调试样例别拿真实订单，报表导出权限和字段映射分开管。字段映射表只留一份，内部报表、上报接口、大屏展示都从它读，避免同一个证件号从三个出口流出。

接口变更怎么应对

字段增删、鉴权方式更换、服务地址迁移，一般会留一段并行期。技术上做三件事：映射层集中，改一处就够，别在每个业务模块里各拼一次报文；保留新旧两版发送能力，出问题能退回；变更后先小批量试跑，用回执和字段校验确认格式再放全量。运维上要留两个平时不用、故障当天却没有就只能干等的开关：能手动暂停上报，能手动指定日期补报。每次变更记录一条：变更内容、生效时间、验证结果、执行人。

被抽查时要能出示的记录

抽查通常不问概念，问的是那天你几点知道超限、做了什么。要能导出的东西包括：分时段预约量、瞬时客流曲线、承载量预警触发记录（触发时间、通知到了谁、采取了什么动作）、上报成功与失败明细、口径说明及变更生效日期、演练与故障处理记录。这些都该是系统里点一下就能导出的，而不是当天临时拼材料——拼出来的材料在口径上很难自洽。