宠物服务门店系统的工程实现：时段库存、预付权益账本与档期防超卖

先说结论

宠物门店类系统看起来是"预约 + 会员"，工程上真正的难点集中在三处：时段库存（工位容量与人员档期取交集，防并发超卖）、预付权益账本（次卡与储值的余次、余额、有效期与跨店结算要有一本可回溯的流水）、档期区间库存（寄养按房型按晚扣减，防重叠占用并保留交接记录）。这三块都属于"出错很难补"的类型：时段卖重了是现场事故，账本对不平是财务纠纷，档期排重了是客户投诉。这篇按三段拆实现要点，最后给模块划分速查。

一、排班与时段库存：工位与人员的双资源建模

图 5：排班侧模块划分——双资源建模、库存扣减、并发约束与工时结算

1. 资源建模

把"可预约资源"拆成两层而不是一层：

• 物理资源：洗护工位、烘干位、住店房型，各自有容量与占用时长；
• 人力资源：美容师/洗护师，带技能标签（可承接项目类型）与日产能上限。

服务项目上挂三个属性：预估基准时长、占用哪类物理资源、需要哪类技能标签。可预约时段 = 按日展开的营业时段 ∩ 物理资源空闲窗口 ∩ 具备技能的人员可用窗口。只有一层资源的系统，在"两个工位三个人"的场景下必然出错。

2. 库存扣减

时段库存建议做成独立的库存行（门店 + 日期 + 时段 + 资源类型 + 已用/总量），预约成功即扣减，取消或改约按规则回补。不要在订单表里用聚合查询实时算余量——并发一上来就会卖重。

3. 并发约束

同一时段的扣减必须收口在一个原子操作里：数据库行锁、Redis 原子扣减或分布式锁三选一，业务代码不直接读改写。同时要做幂等：客户端重复提交、回调重放都不能产生两次扣减。

4. 时长修正

基准时长只是默认值：按体型与毛量给出修正系数，服务人员开工后可手动追加时长并记录原因。没有修正机制，一只长毛大型犬拖两小时后面全排崩。

5. 工时与提成结算

开工/完工打卡要与库存行挂钩：打卡即写入实际占用区间，完工后按实际时长与项目单价生成提成明细。结算数据由任务按日汇总，不靠线下表格。

二、次卡与预付权益：核销账本、有效期与跨店结算

图 6：次卡从发卡到核销的账本流转——每次动作都写独立流水

1. 账本模型：流水是唯一真相

权益余额不要只存一个数字字段，要建"权益账户 + 权益流水"两张表：账户存当前余次/余额与状态，流水记录每一次发放、核销、赠送、冻结、退回。账户余额可由流水重算校验，这是发现对不平的唯一手段。流水表只增不改，冲正走反向流水而不是 UPDATE。

2. 核销与幂等

核销入口有两个：门店端扫码/输手机号，用户端主动出示核销码。两条路径共用同一个核销服务，用业务单号做幂等键；同一张核销单重复提交只出账一次。异常核销（补录、跨天补核）要留操作人与原因。

3. 有效期与状态机

权益账户的状态建议做成：有效 / 临期 / 已冻结 / 已失效 / 已退回。到期前按可配置天数触发提醒（订阅消息或短信），到期后是冻结还是顺延按门店政策配置为策略字段，不做默认动作。关键约束：任何影响客户资产的规则变更都要留版本与生效时间，避免"规则昨天还是这样"的争议。

4. 跨店核销与内部结算

连锁场景下，发卡门店与核销门店往往不是同一家。做法是在发卡时写入两个字段：适用门店范围、跨店核销的内部结算单价（可按时段或项目类型分档）。核销成功即生成一条内部结算记录，按月汇总到总部账，门店之间的"谁卖卡谁出工"矛盾就从人情问题变成数据问题。

5. 退款与折算

退款要能算清三件事：已核销部分按什么口径折算、赠送权益是否回收、跨店消费后的退款如何在门店间回冲。建议在卡模板里把折算规则显式配置化，退款流程生成独立的冲正流水，不允许直接改历史流水。

三、寄养档期：区间库存、防重叠与交接留痕

图 7：前场负责预约与提醒，后场负责区间库存与交接记录

前场 · 预约与提醒

• 按房型展示可入住区间，而不是按"剩余总房间数"；
• 入住与退房日期之间的每一晚都要校验占用，跨月订单同样逐晚扣减；
• 高峰期采用候补队列承接溢出需求，候补转正时给出确认时限，超时自动释放；
• 入住前一天提醒客户携带免疫记录与随行物品，减少现场沟通摩擦。

后场 · 库存与记录

• 区间占用的实现：以"房型 + 日期"为粒度建占用行，插入前做重叠校验（同房型同日期的占用计数不得超过容量）；校验与插入放在同一事务内，靠唯一索引或行锁兜底，防止并发下同一晚被排两次；
• 入住登记：基础状态项勾选（精神状况、皮肤与被毛、有无外伤）、随行物品清单、现场照片；记录由双方确认，作为后续沟通依据；
• 退房核对：对照入店记录逐项核对并再次留档，异常项写入备注；
• 健康异常处置：系统内提供固定的联络与转诊提示语，明确生活服务与动物诊疗的边界，服务人员不给出诊疗判断；
• 影像与隐私：托管期间的实时画面只对本人订单开放，不留公开入口；影像文件设保留期限并按时清理。

四、模块划分速查

| 模块 | 核心职责 | 关键约束 |

|------|---------|---------|

| 资源模型 | 工位、房型、人员技能与产能 | 双资源取交集，单层建模必出错 |

| 时段库存 | 可约时段生成与扣减 | 原子扣减 + 幂等键，禁止聚合实时算余量 |

| 预约中心 | 下单、改约、取消、候补 | 状态机收口，回补与扣减成对出现 |

| 时长修正 | 体型与毛量系数、人工追加 | 追加需记录原因，影响后续排期重算 |

| 权益账户 | 余次、余额、状态 | 余额可由流水重算校验 |

| 权益流水 | 发放、核销、赠送、冲正 | 只增不改，冲正走反向流水 |

| 跨店结算 | 适用范围与内部单价 | 发卡期配置，核销即生成结算记录 |

| 档期库存 | 房型按晚占用与重叠校验 | 事务内校验，唯一索引兜底 |

| 交接记录 | 入住与退房状态留档 | 双方确认，影像设保留期限 |

| 工时结算 | 实际占用与提成汇总 | 打卡即落数据，按日汇总 |

| 权限与脱敏 | 角色分级、敏感信息展示 | 员工端按角色脱敏，操作留审计日志 |

小结

门店类系统的工程重心是"三个库存、一本账"：时段库存、档期库存、资源库存，加上一套只增不改的权益流水。时段库存做不稳，现场就会出现约重；账本做不成流水，客户问"卡里还剩几次"时前台无法自证；档期不做区间校验，节假日必然出现同房双排。这三块在架构期定型，后续加项目类型、加门店、加权益种类都只是配置变更；定型不稳，任何一次改规则都要动核心表。附图三张分别给出资源与时段建模、权益账本流转、档期与交接双通道的结构参考。