做过几个预约类项目之后，我们发现一个问题：前台页面客人挑时间的部分，哪家都差不多；真正出事的都在后台。日历怎么展示、时段怎么切、库存怎么扣，这三块设计不清，上线后客服比开发还忙。今天把预约预定小程序后台最常见的三个坑摆出来，准备做项目的可以对照避一避。这几个坑不分行业，理发店、诊所、球馆、民宿，只要带时段库存的预约系统都会撞上，区别只是撞得早还是晚。
坑一：日历只做了展示，没考虑跨天
住宿类预约是跨天的，今天订明天住后天走；诊疗类是单点的，某天某时段来一次。两套逻辑用同一个日历组件硬套，就会出现订了三天结果库存被扣三次的怪事。日历层要区分住店型和到店型，住店型按起止日期锁房，到店型按日期加时段锁位，数据结构一开始就要分开。
坑二：时段切得过细或过粗
切到十分钟一档，看着灵活，实际客人在几十个选项里挑花眼，转化率反而低；切到半天一档，又会浪费产能。经验值是：服务类三十到六十分钟一档，场馆类一小时起步，咨询类半小时。项目时长不同的，按项目绑定时长模板，别让一次烫染把理发时段的逻辑撑爆。还有一个隐蔽点：时段要不要允许跨档。客人做九十分钟的项目卡在两档中间，系统要能自动合并相邻空档，不然前台天天手工调单。这类边界场景不写在需求里，开发就按最简单的做，上线后吃亏的是运营的人，返工的钱比写文档贵得多。
坑三：库存扣减没有原子性
两个客人同时提交同一时段，如果代码没做锁，两边都能下单，超卖就这么来的。这类并发问题在活动日尤其致命。定预约预定小程序的开发需求时别只看页面效果，问清楚库存扣减用什么机制、有没有做过压测。一块场地、一个技师、一间房，本质都是库存单元，逻辑必须唯一。
- 提交订单即时锁库存，超时未支付自动释放
- 退款取消后库存即时回滚，日历同步刷新
- 后台改班表、改房态要和线上库存联动，不能两张皮
给两条建议：写需求文档时把日历、时段、库存三块的规则逐条列出来，宁可啰嗦也别含糊；选开发团队时直接问并发和超卖的解决方案，像比格网络这类做过多个预约项目的团队，这三个坑基本都趟平过，能省你不少试错成本。预算紧的，宁可先做窄做稳，把单一场景跑顺，也别一上来铺十几个场景，改起来到处都是债。
