既然支付需要网络，为何还要本地运行？
我们经常会遇到这样的质疑：
“既然微信 / 支付宝支付一定要联网，那你做离线 App + 局域网还有什么意义？
不如直接做成一个公网网站。”
这是一个非常合理的问题，也是我们在设计之初认真讨论过的点。
实际上，我们确实做过网站版本，也因此踩了不少坑，下面是我们的完整看法。
1）工具的主业务不是支付，而是点单与库存管理
本软件解决的核心问题，并不是“如何完成支付”，
而是摊位在高强度现场环境中最容易出问题的那一整条业务链路：
- 顾客点单（自助下单 / 改数量 / 备注）
- 订单队列（叫号 / 出单 / 撤单 / 补单）
- 库存扣减（避免超卖、缺货提示）
- 统计与对账（当日销量、品类统计、热销排行）
这些都属于摊位自身的核心业务逻辑，它们有一个共同要求：
- 不能依赖场馆公网
- 在断网或弱网下也必须可用
- 多设备协同也要稳定（摊主机、展示屏、出单屏、备用设备）
因此我们最终选择了：离线 App + 局域网 的架构。
离线方案的意义，是保证「点单 → 库存 → 出单 → 统计」这条链路永远不崩，
因为它直接决定摊位能不能正常运转。
至于支付，我们从一开始就将它视为一个解耦的外部环节：
系统只负责展示收款码，并不直接参与任何支付逻辑。
2）支付并非主业务，它可以独立发生，甚至不必严格同步
在真实的漫展现场，支付本身就存在大量“非标准流程”的做法，例如：
- 顾客先下单，拿到订单号 / 金额，再去扫码支付
- 高峰期先把订单下完，稍后找空位慢慢付
- 多人拼单，由其中一人集中支付
- 摊主听到账语音或看到支付完成页后，手动确认
因此我们的设计原则是：
- 点单 / 库存 / 订单队列：在局域网内稳定运行
- 支付：完全解耦，不强依赖实时联网回传
也就是说：
即使支付因为网络问题需要多尝试几次，甚至稍后再完成，
摊位的订单管理系统依然是稳定的，不会被拖垮。
支付需要联网，并不意味着点单和库存管理也必须依赖公网；
更不意味着「必须付完款，才能下单」。
3）“有网但很差”是漫展常态，而公网服务对此极其敏感
国内互联网普遍覆盖，并不代表漫展现场能保持可靠连接，可能只是保持最低限度的“有网”。
常见情况包括：
- 人群密集导致网络拥塞：高延迟、丢包、时断时续
- 场馆 Wi-Fi 不稳定：需要登录页、频繁掉线、带宽被挤占
- 公网系统加载重： 文件资源 / 大图 / 脚本
这会导致一个很典型的现象：
公网网页或云端系统经常卡死、白屏或请求失败，
但微信 / 支付宝扫码支付仍然“断断续续”可以完成。
原因在于两者对网络的要求完全不同：
- 公网网站
需要连续加载大量资源、频繁建连、多个域名请求
→ 在弱网环境下极易失败 - 扫码支付
平台针对弱网做了大量优化（重试、连接复用、就近节点）
→ 往往只要某一次请求成功提交即可完成支付
如果将「点单 / 库存 / 订单同步」也放在公网服务上，就会出现：
- 点单页面打不开或加载不上素材图片
- 订单同步延迟、丢单、重复单
- 摊位需要不断刷新、重登、重试
- 高峰期越忙越容易崩溃
而局域网方案可以让摊位的核心业务完全绕开网络导致的不可控因素。
局域网保证主业务稳定；
扫码支付则利用平台自身的弱网优化“勉强可用”。
推荐的现场工作流
- 顾客连接摊位局域网（或扫描屏幕二维码进入点单页面）
- 完成下单，获得 订单号 + 金额
- 顾客使用自己的网络扫码支付（微信 / 支付宝）
- 摊主听到账语音或看到支付完成页 → 一键标记已付款
- 出单端按队列制作并交付
这套流程的关键在于：
- 摊位内部系统不依赖公网
- 支付失败不会拖垮点单系统
- 高峰期不会因为网络波动导致整体停摆
离线 App 的意义究竟是什么？
- 离线 App 的意义不是「离线完成微信 / 支付宝支付」
- 而是保证摊位的核心业务（点单 / 库存 / 出单 / 统计）始终稳定
- 支付作为外部链路被解耦存在，并利用平台自身的弱网优化完成
支付需要互联网 ≠ 离线点单没有意义。
真正决定摊位是否能跑起来的，是你能否在任何网络条件下稳定管理订单与库存。