景区票务系统选型的技术尽调清单：从并发、数据到二次开发的 12 个必查项

近期公开报道中有两起信息化项目"建了用不起来"的案例：山西某旅游项目投资 9832 万元建成后长期空置；贵州某县"智慧城市"项目投资 8000 多万元，8 个子系统实建 7 个、6 个停用闲置。

从技术尽调视角看，这类项目的问题高度集中。本文把景区票务系统选型时应当核查的技术项整理成一份清单，供技术负责人参考。

1. 峰值并发承载

要求提供同规模景区的真实峰值数据：单日售票量、峰值 QPS、售票与检票接口的 P99 响应时间。旺季（黄金周）单日数万人次是常态，压测报告比功能演示更有说服力。

2. 核心链路降级策略

售票、检票、对账三条链路中，检票链路必须可降级（如断网离线核销 + 恢复后补传）。询问是否有离线模式与补传机制。

3. 硬件协同的稳定性

闸机、自助售票机、手持检票机与后端的长连接如何维持？心跳间隔、断线重连策略、异常设备告警机制是否完善。

4. 故障恢复指标

明确 RTO（恢复时间目标）与 RPO（恢复点目标）。票务系统涉及资金与入园凭证，RPO 应尽可能趋近于 0。

5. 统一数据模型

订单、票种、渠道、设备、会员是否有统一编码体系？多渠道（窗口/OTA/小程序/自助机）售检票数据能否汇聚到同一套模型。

6. 数据可导出与开放接口

数据能否批量导出？是否提供 API 供外部报表/BI 对接？数据取不出来，系统价值会被大幅折损。

7. 经营指标是否系统内计算

渠道销售占比、核销率、二次消费贡献、客流时段分布，是系统直接输出，还是需要人工在 Excel 里拼？

8. 数据归属与部署位置

数据落在谁的服务器上？是 SaaS 托管还是私有化部署？数据的所有权与使用权如何在合同层面界定。

9. 渠道适配是否插件化

新增一个 OTA 渠道（如抖音来客）是否需要改动主流程代码？理想的架构是适配器/插件层，新增渠道不动核心。

10. 票务规则是否可配置

分时预约、计次票、年卡、套票、隐藏票等规则，是通过配置表达，还是硬编码在代码里？规则可配置 = 业务变更无需发版。

11. 交付物完整性

是否交付全部源码、数据库脚本、部署文档、接口文档？只交付编译产物的项目，后续维护会被供应商绑定。

12. 交接可行性

一个独立的第三方团队，能否仅凭交付物接管系统？这是判断"是否被锁死"的终极问题。

票务系统的技术尽调，核心是三个问题：核心链路能不能扛住峰值、数据能不能流得动、系统能不能被长期维护。

把这 12 项查清楚，比对比功能清单更有价值。

（本文为技术经验分享，案例均来自公开报道。）