摊盒的适用边界
摊盒不是一个试图覆盖所有销售场景的通用系统。
它服务的是一个明确、具体、且高频出现的使用环境——漫展摊主。
为了保证在这个环境下足够稳定、简单、可预期，我们有意放弃了一些能力。
本页面用于说明：
- 在什么情况下，摊盒会非常合适
- 在什么情况下，你应该考虑其他方案
摊盒主要适用的场景
摊盒优先面向以下类型的使用环境设计：
1. 实体现场出摊
- 漫展 / 同人展 / 展会的实体摊位
- 摊主与顾客面对面完成交易
- 以“快速点单 → 出单 → 交付”为核心流程
2. 网络质量不可预测的环境
- 场馆内蜂窝网络拥塞
- 公共 Wi-Fi 不稳定或存在隔离
- 无法保证持续、可靠的公网连接
在这些环境下，系统稳定性优先级高于远程能力。
3. 商品数量较多、人工容易出错的摊位
- 商品种类多、价格不统一
- 容易出现漏单、错单、算错钱
- 需要清晰的库存扣减与售罄提示
摊盒在这类场景中，可以显著降低人为失误。
4. 需要当日统计与快速对账
- 展会结束后需要立刻汇总销量
- 需要给主催或社团做寄售结算
- 不希望回家后再翻纸质账单或聊天记录
由于数据都被保存在本地设备，摊盒可以快速生成报表，方便对账。
5. 对数据自主性有要求的用户
- 不希望将销售数据上传云端
- 不希望依赖第三方 SaaS 服务
- 希望数据完全掌握在自己设备中
摊盒刻意不覆盖的需求
为了保持系统的稳定和适用性，摊盒明确不覆盖以下场景与需求。
1. 远程或跨城市实时协作
- 异地同时管理多个摊位
- 主催在远程实时监控所有销售数据
- 多城市、多会场的统一后台
这类需求更适合 公网 SaaS 或云端系统。
2. 强制支付闭环的业务模型
- 必须“先付款才能下单”
- 强依赖支付回调自动完成订单
- 需要严格的资金与订单自动对账
摊盒的设计假设是：
支付可以作为独立环节，由人工确认完成。
因为涉及支付环节需要向相关平台（微信 / 支付宝）申请接口权限，需要负责的资质认证，这对个人门槛太高。
3. 复杂的营销与会员体系
例如：
- 会员积分、等级系统
- 优惠券、满减、拼团
- 自动化营销与数据分析
摊盒更关注“现场可用”， 而不是“长期运营型功能”。 我们会在将来考虑通过插件等方式支持部分营销功能，但不会内置复杂的体系。
4. 多租户与权限管理
- 多角色、多层级权限
- 多商户共用一个系统实例
- 面向商业化运营的平台需求
这超出了摊盒的设计目标，我们面向的是“同人社团”级别的个人和小团队摊主。
关于这些取舍的说明
上述“不支持”的能力，并不是技术上无法实现。
而是基于以下考虑做出的主动取舍：
- 每增加一个能力，都会引入新的复杂度与不稳定性
- 不能让软件依赖于任何中心化服务器，以防鼓掌或我们停止维护
- 不能让摊主进行复杂的配置与资质验证，尽可能“即下即用”
摊盒选择把有限的复杂度，用在最容易出问题、也最值得被系统化的那一段流程上。
如果你的需求不在这个边界内
如果你的使用场景明确超出了上述范围：
- 选择其他解决方案是完全合理的
- 摊盒并不是为此而设计
我们更希望你：
在正确的场景中使用摊盒，而不是勉强适配一个不合适的工具。