按摩平台订单状态流程是一套六个正向态加三个终态的设计：待支付、待接单、待服务、服务中、待确认、已完成，另有已取消、已退款、已关闭。整套流程的可靠性不靠人盯，而靠三个定时任务兜底——未支付超时关单、接单超时自动退款退券、顾客久不确认自动完成。
服务类订单和商品订单最大的区别是「履约必须有人应」。商品付款后仓库会发货，服务付款后要等商家接单——这中间那段等待，是整条链上唯一可能空转的地方。
按摩平台订单状态流程是怎么设计的？
六个正向态串成主链，三个终态接住所有异常出口。
主链是：待支付 → 待接单 → 待服务 → 服务中 → 待确认 → 已完成。终态是：已取消（未支付阶段中止）、已退款（已支付后中止）、已关闭（其他终止情形）。
设计上有一条隐含原则：每个状态只允许一个角色推进动作。 待支付由顾客推进（付款或取消）；待接单由商户推进（接单或拒单）；待服务由商户或顾客推进（核销或开始服务）；服务中由商户推进（提交完成）；待确认由顾客推进（确认或申请退款）。角色不交叉，责任就不会互相推。
这条原则解释了很多细节。比如为什么「商家提交完成」之后还要有「待确认」这一态——如果商家一提交就结算，顾客失去申诉窗口；如果顾客不确认就一直挂着，商家拿不到钱。加一态加一个自动兜底，两个问题同时解决。
六个状态各自对应什么动作？
付款、接单、核销或上门、开始服务、提交完成、顾客确认，每个动作都有明确的操作者与时限。
待支付：顾客提交订单后进入，系统给出支付时限（素材里是十五分钟）。此时可取消、可继续支付。
待接单：支付成功进入。商户看到提醒，可接单或拒单；拒单必须选或填原因，系统预设了几类常见理由。上门订单接单时必须指派一名技师，且只能指派已启用、具备该服务能力的技师——这一条把「接单」和「派工」绑成了一个动作，避免接了单却没人去。
待服务：接单后进入。到店订单等顾客到店核销，输入六位核销码由系统校验；上门订单则由商家点击开始服务。
服务中：核销或开始服务后进入。技师在服务，商户可以在结束后提交完成。
待确认：商户提交完成进入。顾客可确认完成，也可申请退款。
已完成：顾客确认（或系统自动确认）后进入，订单转入结算流程，按平台设定的结算天数转为可提现余额。
为什么待接单是最危险的一环？
因为钱已经收了，服务还没开始，这一段完全依赖商户的响应速度。
顾客视角：我付了钱，页面显示「等待商家接单」，十分钟过去没动静。他不知道是商家忙、没看见、还是不想接。这种不确定性对体验的伤害比「没有这家店」更大。
商户视角：忙的时候顾不上看后台，一个午市高峰过后发现积了七八个超时单。
平台视角：这些单如果一直挂着，就成了「已付款却无人履约」，投诉、退款、差评全部落到平台头上。
所以系统在这一环设了三道防护：一是工作台的待接单提醒，把「超过接单时限订单会被自动取消并退款」这句话直接写在提醒里；二是接单时限的强制约束，超时自动取消并全额退款、退还优惠券；三是拒单必须填原因，让平台能看到商户拒单的真实分布——是价格问题、距离问题，还是单纯不想接。
拒单原因的数据价值常被低估。如果某个区域大量拒单原因是「距离太远」，那就该调服务半径；如果集中在某个服务项目，那就该看定价。 这些是运营决策的输入，不是客服记录。
三个定时任务分别兜什么漏？
兜住「不付款、不接单、不确认」这三种沉默。
第一种：未支付超时自动关闭。 顾客下单后不付款，订单占着优惠券和库存（服务名额），必须释放。系统按支付时限自动关闭，券退回顾客券包。
第二种：已支付但商家超时未接单，自动取消并全额退款。 这是最重要的一条。它把「商家不响应」的后果从「顾客等着」变成「系统兜住」，退款的同时退还优惠券。退券这个细节很关键——顾客可能为了这单专门领了券，不退券等于让他白白损失一次优惠机会。
第三种：商家提交完成、顾客长时间未确认，自动确认完成并进入结算。 没有这一条，商户的应收款会无限期挂起。有了它，等待被切成一个有上限的窗口。
三个任务之外，系统还有两个定时任务分别管资格与资金：每天检查商家资格是否到期并自动锁定（锁定后在顾客端立即下线），每天扫描已到达结算时点的订单并自动完成结算入账。这五个定时任务构成了整套系统的「自动运转骨架」，少了任何一个，就需要人工每天去补。
顾客确认为什么需要自动完成兜底？
因为「忘记确认」是常态，而商户的收入不能建立在顾客的记性上。
真实场景里，顾客做完服务，付完钱，人走了，很少会再打开小程序点「确认完成」。如果不设自动确认，商户的订单会永远停在待确认，钱永远不到账。
自动确认的时限通常给得比较宽（几天），理由是留出申诉窗口：顾客如果对服务不满意，有足够时间申请退款；过了这个窗口没有异议，视为认可。
需要注意的是这条规则与退款的关系。自动确认之后并不等于退款通道关闭，而是从「订单内退款」转为「售后投诉」，由平台介入处理。这个转换点要写清楚，否则顾客会认为「一确认就不能退」，商户则会认为「确认了还能退，确认毫无意义」。
到店与上门的路径差在哪个状态？
差在「待服务」这一态：到店是核销码，上门是技师上门。
两条路径在前面几态完全一样（选服务、选时间、选券、支付、接单），从待服务开始分叉：
到店路径是 顾客到店 → 出示六位核销码 → 商家输入校验 → 开始服务。核销码是一次性的，校验通过后即失效，防止重复使用。商家端还提供扫码与手动输入两种方式，并在页面上列出所有待核销订单，避免顾客找不到码时无法处理。
上门路径是 商家在接单时已指派技师 → 技师上门 → 商家点击开始服务。顾客在订单详情里能看到被指派技师的姓名、头像和简介——这一条是安全感的来源，顾客需要知道来的是谁。
两条路径在「完成」环节又合流：都是商家提交完成、顾客确认。分叉只发生在中间一段，这是好设计，因为状态机分叉越多，异常处理越复杂。到店与上门共用一个状态链、只在待服务的动作上区分，既覆盖了两种履约方式，又没有让状态机变成两套。
状态设计出错会有什么后果？
最直接的后果是钱和券卡在中间态，第二层后果是纠纷没有归属。
常见的错误有三种。一是状态太少，比如把「待接单」和「待服务」合并，商家一接单就等于开始服务，核销环节丢失，到店订单无法验证顾客是否真的来了。二是状态太多，为每种业务单独加态，最后没人说得清某个态该谁动。三是终态不闭合，取消、退款、关闭三种终止情形混成一个「已关闭」，导致财务对账时分不清是退款还是作废。
判断一套系统的状态机是否可靠，看三个地方就够了：终态是否分得清、每个态是否只允许一个角色推进、异常出口（超时、拒单、退款）是否有自动兜底。 这三条都满足，日常运营基本不需要人工盯单。
和上门服务预约系统源码里提到的「迟到与跳单提醒」对照，那类功能是状态机之上的运营增强——提醒不改变状态，只是把「快要出问题」提前告诉相关人。状态机负责正确性，提醒负责体验，两者不能互相替代。