先说结论
陪诊平台的工程核心是三件事：把预约到结算的全过程做成状态机收口的订单链路、把时段库存与人员排班做成可校验的派单调度、把就诊人敏感信息的保护做进数据模型而不是事后补丁。小程序页面本身反而是简单的部分。这篇按订单状态机、排班派单调度、敏感数据保护三段拆实现要点。
一、订单状态机：全过程收口，履约节点留痕
陪诊订单的特殊性在于「服务发生在医院现场、过程不可回放」，所以状态机设计与留痕深度直接决定纠纷处理能力。设计要点：
- 状态机收口：预约 → 待支付 → 已派单 → 服务中 → 已完成 → 已结算，每个状态迁移定义唯一的前置状态与触发事件，非法迁移在服务层直接拒绝；取消与退款走独立的终态分支，不与正向链路混用；
- 履约打卡联动：到院、取报告、交接等关键节点由陪诊师端打卡（拍照 + 时间戳 + 定位）触发状态迁移，打卡记录只允许追加不允许修改；
- 超时预警：已派单超时未打卡、服务中超长停留等异常进入预警队列，人工介入通道与状态机解耦——介入动作本身也落日志；
- 幂等与冲正：支付回调、结算入账带幂等键，同一订单的结算动作靠数据库行锁保证只执行一次；退款场景下已结算佣金的冲正路径（余额冲抵、负记录、提现拦截）在建模阶段就要定下来。
图 5：陪诊订单状态机与异常分支设计
二、排班派单调度：时段库存不超卖，派单模式可配置
图 6：排班派单调度的五段流水线
- 时段库存：服务时段按「陪诊师 × 日期 × 半天/全天」建模为库存单元，下单时行锁扣减，避免同一时段被超卖；陪诊师排班变更触发的库存回收走事件补偿，不直接改已下订单；
- 候选匹配：按城市分区、服务类型、评分、当前负荷筛出候选集，匹配逻辑只做「缩小范围」，最终派给谁由派单模式决定；
- 派单模式分流：抢单（先到先得）、手动派（后台调度员指定）、自动派（按权重）三种模式配置化，同一平台可以按城市开不同模式；
- 接单确认：派单后设置确认时限，超时未接自动流转下一候选或回池，避免订单挂在单人手里超时；
- 履约联动：接单确认后生成履约清单（打卡节点、服务内容、备注），与服务端打卡记录一一对应，完成后才能进入结算。
调度模块的坑通常在时区与边界：跨零点的全天单、加时需求、陪诊师临时请假，这三类场景的库存与状态处理要在测试用例里显式覆盖。
三、敏感数据保护与业务留痕：两条通道分开建
图 7：敏感数据保护与业务留痕的双通道设计
数据保护侧：
- 就诊人姓名、病情描述等字段按敏感个人信息标准处理：采集前明示授权、传输与存储加密、后台展示脱敏（默认掩码，查看明文需权限并记审计日志）；
- 采集最小化：只收履约必需字段，页面上的「选填」比后端的「可空」更前置——能不收的字段从表单阶段就去掉；
- 数据导出配权限分级，导出行为进审计日志。
留痕审计侧：
- 资质审核记录（证书、健康证明、审核人与结论）全量落库、可追溯到人；
- 订单、打卡、结算、冲正记录只允许追加不允许删除；
- 后台敏感操作（派单干预、提现审核、资质变更）写操作日志，操作人、时间、前后值三要素齐全。
数据保护策略求严，审计策略求全，两套逻辑独立演进；耦合在一起时，一次审计需求的调整可能牵动加密字段的结构，得不偿失。
小结
陪诊平台的复杂度集中在三处：订单状态机的收口与冲正、时段库存与排班派单的可校验调度、敏感信息的分级保护与全程留痕。把这三块做扎实，页面层的迭代成本很低；反过来，跳过状态机与库存建模直接堆页面，后期每一次规则调整都要伤筋动骨。
