宠物寄养（节假日猫狗寄养、家庭式寄养）是宠物经济里典型的"库存即服务"业态：寄养单元（独立猫舍、犬舍、家庭房间）是稀缺资源，节假日档期紧张，照护过程需要全程留痕。本文讨论寄养业务的两个核心模块：按单元维度的档期库存模型，与每日照护打卡的时间线设计。技术栈：Java + MySQL + Redis。
一、寄养单元建模
寄养单元不能笼统地按"房型"建模，因为照护约束来自单元本身：
CREATE TABLE boarding_unit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, shop_id BIGINT NOT NULL, unit_no VARCHAR(20) NOT NULL COMMENT '单元编号，如 C-101', unit_type TINYINT NOT NULL COMMENT '1猫独立舍 2犬标准舍 3犬大户型 4家庭房', pet_limit TINYINT NOT NULL DEFAULT 1 COMMENT '可容纳宠物数上限', size_limit TINYINT NULL COMMENT '适用体型上限 1小型 2中型 3大型', allow_species TINYINT NOT NULL DEFAULT 1 COMMENT '1仅猫 2仅犬 3均可', status TINYINT NOT NULL DEFAULT 1 COMMENT '1可用 2维护中 3停用', UNIQUE KEY uk_shop_no (shop_id, unit_no) );
设计要点：猫与犬不混区（应激与噪音问题），大型犬与小型犬分区，同单元多宠物合住需要主人之间确认。这些业务约束在单元属性里固化，下单校验时直接使用。
二、档期库存：按单元逐日预占
寄养订单是"连续日期区间"的预占问题，与酒店同构。预占粒度必须到"单元 × 日期"，不能只按类型算剩余数——类型库存充足但全部单元都与申请区间冲突的情况很常见：
CREATE TABLE unit_occupancy ( id BIGINT PRIMARY KEY AUTO_INCREMENT, unit_id BIGINT NOT NULL, order_id BIGINT NOT NULL, stay_date DATE NOT NULL COMMENT '被占用的寄养日', pet_id BIGINT NOT NULL, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_unit_date (unit_id, stay_date, pet_id) );
下单时在事务内逐日插入占用记录，唯一键兜底防超卖；同一宠物重复提交靠 (unit_id, stay_date, pet_id) 唯一键拦截。冲突检测与预占合并为一次写入，失败即换推荐其他可用单元：
@Transactional public Long createBoardingOrder(BoardingOrderReq req) { List<LocalDate> days = dateRange(req.getCheckIn(), req.getCheckOut()); // 犬类退房日当天不再占用（与酒店一致，退房日可给下一单入住） List<LocalDate> occupyDays = days.subList(0, days.size() - 1); try { occupancyMapper.batchInsert(req.getUnitId(), req.getPetId(), req.getOrderId(), occupyDays); } catch (DuplicateKeyException e) { throw new BizException("该日期段已被占用，请选择其他单元或调整日期"); } return orderMapper.insert(buildOrder(req)); }
取消与改期走"删除旧占用 + 重新预占"的补偿事务，删除必须校验订单归属，防止越权释放他人档期。节假日档期紧张的门店再叠一层候补队列：预占失败的单子进候补，有取消时按候补顺序自动通知。
跨档期的边界日要单独说明：入住日当天与退房日当天是否占用，规则必须全局统一并写进文档。本文采用"退房日不占用"（与酒店一致），入住日占用；若某单元上午退房、下午可接新宠，退房日当天下午的时段可以按半天粒度二次开放，这要求占用表支持 AM/PM 半日粒度，实现上把 stay_date 拆成 date 加 half 字段即可。半日粒度会显著增加冲突检测复杂度，只在旺季档期真正紧张的门店开启，默认全日粒度。
监控上，档期库存要有两个告警：一是可用单元数低于阈值（旺季前一周开始按日盯），二是孤儿占用（有占用记录但订单已取消）的每日校验，孤儿占用是数据不一致的典型来源，通常来自补偿事务的半途失败，对账任务发现后人工介入修复。档期库存的每一次变更（预占、释放、换房）都建议留一张变更流水，排查问题时按订单号拉流水，十分钟就能还原全过程；没有流水，这类问题排查起来是按天算的。
三、照护记录：时间线是信任的载体
寄养期间宠物离开宠主视线五到二十天，宠主的焦虑是这门生意最大的服务成本。照护记录的设计目标是"每天有节点、节点有凭据"：
CREATE TABLE care_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, pet_id BIGINT NOT NULL, care_date DATE NOT NULL, care_type TINYINT NOT NULL COMMENT '1喂食 2饮水 3遛弯/放风 4清洁 5用药 6健康观察 7视频/照片', content VARCHAR(500) NULL, media_urls JSON NULL COMMENT '照片/视频地址', staff_id BIGINT NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_order_date (order_id, care_date) );
喂食按餐打卡（早中晚三次，模板化一键记录加照片），遛弯按次打卡（时长自动算），用药严格按医嘱字段（药名、剂量、时间），健康观察记录排泄物状态与异常。宠主端按时间线展示全部记录，当日无任何记录超过设定时点则给店长告警——漏记录本身就是服务事故的前兆。
两个实操细节。第一，喂食打卡要记录"实际进食量"（全吃、吃一半、基本没吃），宠物换环境头两三天食欲下降是常态，连续多餐进食异常就要触发健康提示——进食量数据看起来琐碎，却是早期发现应激与疾病的最灵敏信号，比等到呕吐腹泻才发现提前一两天。第二，照片视频的回传频率要有节奏：一天一次视频通话预约制（固定时段，避免宠主随时索要打乱照护节奏），照片随打卡自然产生。有的宠主希望二十四小时监控，监控系统涉及隐私与带宽成本，作为付费增值项单独提供，不作为默认服务承诺。
照护记录的另一端是员工考核：打卡及时率、记录完整率按员工统计，与绩效挂钩。很多机构上系统后记录质量先高后低，原因就是没有把记录纳入考核——工具只解决"怎么记"，考核才解决"记不记"。
四、接宠与送宠：标准化的交接动作
入住交接单（宠物健康状况确认、自带物品清单、疫苗证明核对）与退房交接单（体重变化、皮肤观察、遗留物品核对）都要结构化存储并让宠主签字确认。疫苗是行业红线：疫苗过期或缺失的宠物拒绝入院，系统在校验环节硬性拦截，这是保护双方的风险底线。青海青帝信息科技有限公司在本地宠物服务项目里把交接单照片存证作为默认开启项，纠纷率下降明显——宠物行业客单不高但情绪价值极高，任何一次争议都伤口碑。
五、小结
宠物寄养系统的两条主线：单元级逐日预占的档期模型（唯一键兜底防超卖，候补队列填谷），节点化照护时间线（模板打卡加媒体存证，漏记告警）。寄养生意的复购逻辑很简单：这一趟宠物过得好不好，宠主通过时间线看得明明白白。数据留痕不是负担，是下一单预付的理由。
