老龄化加速、独居人群扩大、异地就医常态化这几年医疗陪诊的需求涨得非常快。但真正做过这行的人都知道医疗陪诊不是跑腿挂号那么简单——它涉及医疗流程理解、现场应急处理、隐私保护、订单撮合和信任机制是一个典型的线上线下融合的本地生活服务场景。我最近完整跟了一个医院陪诊APP微信小程序的项目从零到上线今天把这套系统从需求定位、功能模块拆分到技术实现、踩坑记录全部分享出来。不管你是打算自研一套陪诊系统还是只想了解陪诊平台背后的功能全貌这篇都能给你一个可落地的参考。1. 医疗陪诊系统的开发背景与核心需求定位1.1 什么叫医疗陪诊它到底解决什么问题医疗陪诊本质上是一个服务型平台一端连接需要陪诊服务的患者用户端另一端连接有医疗场景服务能力的陪诊员服务端平台负责撮合、调度、支付、售后和监管。但这里的核心不是撮合而是信任和确定性。患者把就医这件事的一部分托付给陌生人平台必须通过功能设计来消除这种不确定性。比如陪诊员有没有资质、是否按时就位、服务过程中是否可靠、就医信息是否泄露这些都得靠系统能力来兜底。我一开始和很多人一样以为陪诊系统的核心模块是下单和支付做完了才发现真正决定产品生死的是服务过程的可控性。陪诊员有没有按时到医院签到用户在医院里面排队等了多久陪诊员有没有擅自离岗这些感知数据如果没有被系统记录和量化平台就是个空壳子出了纠纷连凭证都没有。所以一套合格的陪诊系统至少要满足三个层面用户层面快速下单、价格透明、过程可见、服务可评。陪诊员层面接单灵活、路线清晰、服务流程有指引、收入结算透明。平台层面订单全链路可追踪、服务质量可考核、数据可沉淀。1.2 目标用户与服务场景拆解陪诊服务的典型用户可以分为四类每一类对系统的需求点差异很大用户类型典型场景核心需求异地就医患者来到陌生城市不熟悉医院流程挂号协助、路线指引、取报告代办老年患者子女不在身边不会用智能设备全程陪伴、方言沟通、用药记录孕产妇/术后康复者行动不便需要搀扶和照护轮椅接送、全程搀扶陪同忙碌的都市白领没时间陪家人看病代排队、代取药、远程同步信息我在做需求调研时发现一个很关键的点不同用户对陪的深度要求完全不同。有些用户只需要陪诊员帮忙排队、取药有些用户要求全程贴身陪同甚至需要记录医嘱。如果系统在商品和服务包层面不区分清楚后续的定价和履约都会出问题。所以我们把服务拆成了几个基础单品普通陪诊全程陪同按小时计费代办服务取报告、取药、排队按件计费专家陪诊指定医院/科室的深度陪诊按半日/全日计费住院陪护跨天服务需要特殊资质的陪诊员这个服务包的拆解直接影响数据库设计和订单系统设计后面我会详细讲。1.3 为什么选择小程序APP双端而不是只做小程序开发之前团队也争论过到底只做微信小程序还是小程序APP一起上。最终我拍板做了双端理由很实际小程序负责获客和轻量使用。微信内扫码即用不需要下载安装传播路径短很适合在医院的场景里被快速拉起。陪诊服务的用户中老年人占比不小很多老年人手机上就一个微信小程序对他们来说是唯一可行的使用方式。APP负责重度用户和陪诊员端。陪诊员每天要刷新订单、接单、导航、签到打卡、上传凭证这些操作频繁且需要后台驻留能力。小程序在iOS和Android上的后台行为受限比较多而且频繁切换应用很容易被微信回收直接影响接单体验。陪诊员端我强烈建议做成原生APP或者至少是uni-app打包的APP。另外还要考虑订阅消息和推送的问题。小程序虽然能用订阅消息但一次性订阅的限制很烦人用户授权意愿在真实场景下不高。APP端用厂商推送通道到达率要稳得多。2. 医疗陪诊系统的核心功能模块拆解2.1 用户端功能模块小程序/APP通用用户端的核心不是功能多而是下单路径短、状态感知清晰。我列一下最终落地的用户端功能清单首页与分类导航首页要承担两件事让用户快速理解服务内容以及让用户快速发起下单。我们首页直接放了四个金刚区入口——我要陪诊代办跑腿预约下单老人模式。特别是老人模式UI字号放大到34px把预约、联系陪诊员、我的订单三个按钮放到首屏这是做完用户调研之后特意加的老人用户根本不需要看广告位和活动页。服务详情页服务详情页常规的做法是堆图片和介绍我们这里最核心的转化要素是价格透明和取消规则。陪诊服务客单价不低用户在下单之前最关心的是这个价格包含什么不包含什么。我们把费用包含和费用不包含做成两个固定区块比如不包含挂号费、不包含检查费、不包含加急费用这些必须在用户确认下单前完成勾选确认。下单与订单确认下单页要收集的信息服务类型、医院、科室、日期、病情描述、联系人信息。这里有个细节陪诊订单必须有紧急联系人字段而且必须是能打通的手机号。陪诊过程中如果用户病情突然有变化陪诊员联系不上家属这是很大的安全隐患。在线支付与优惠支付我建议直接接微信支付和支付宝不要自建支付渠道。陪诊服务是预付制用户先付款、平台再派单这样可以解决信任问题。优惠体系这块第一版先做新客立减和邀请码不要做太复杂的满减因为陪诊订单的时间属性很强不像外卖那样适合凑单。订单动态与消息通知订单动态是用户端最有价值的功能。从下单成功、陪诊员接单、陪诊员已出发、已到院、已签到、服务中、已完成、已评价整个链路至少八个状态节点每个节点都要实时推送给用户。这个不只是给用户安全感也是平台服务留痕的依据。投诉与售后医疗场景的售后和普通电商完全不同它往往涉及医疗责任边界。所以我们没有开放一键退款而是把投诉和售后做成了反馈通道人工客服介入的模式。用户发起售后后系统生成工单客服在15分钟内必须响应。这个响应时限成了我们考核客服团队的硬指标。2.2 陪诊员端功能模块陪诊员端APP是整个系统里我认为做得最重的部分因为陪诊员的工作流非常依赖移动端的效率工具。接单大厅与订单筛选接单大厅的核心是让陪诊员快速找到离自己近、价格合适的订单。我们实现了基于地理位置的距离排序通过LBS检索附近2公里、5公里、10公里范围内的待接订单并且支持按医院筛选。接单模式上我们做了手动抢单制没有做平台派单制。原因很简单陪诊员对路况和医院熟悉程度差异很大强制派单会导致服务体验不可控。派单制适合运力标准化程度高的场景比如网约车陪诊服务高度依赖人所以让陪诊员自己选。接单后工作台工作台要覆盖一个完整服务周期的工具导航到院调用第三方地图SDK签到打卡LBS定位时间戳服务拍摄留证拍照自动添加水印医嘱记录文字录入语音转文字陪同过程中的实时位置共享用户端可见结束服务触发用户评价通知这里我要特别讲一下打卡留痕的意义。医疗陪诊最容易出纠纷的地方是到底服务了多久和有没有到场服务。我们强制要求陪诊员在进入医院半径500米范围内才能点击到达打卡在离开医院范围时触发离开提醒如果陪诊员在服务过程中离开医院范围超过30分钟系统自动标记异常并推送消息给用户。这些自动化的风控机制比事后翻聊天记录靠谱太多了。收入与结算陪诊员的接单佣金结算必须做到可查可追溯。我们的方案是每次服务完成并且用户无投诉后T1日自动结算80%佣金剩余20%在无投诉满7天后释放。这个设计保护了平台利益也让陪诊员有持续服务的动力。2.3 管理后台功能模块管理后台是很多初次做陪诊系统的人容易忽略的部分但真正运营起来才发现后台决定了平台能不能规模化。用户管理用户基本信息、历史订单、投诉记录、黑名单标记。陪诊员管理入驻审核、资质上传与审核、服务区域配置、接单状态管控、服务考核。订单管理订单列表、状态筛选、异常订单标记、退款处理、工单流转。财务管理交易流水、佣金结算、提现管理、发票管理。运营配置服务项目配置、价格配置、优惠券配置、公告管理。数据统计订单量趋势、服务品类分布、用户增长、陪诊员服务质量排名。数据统计这块我强烈建议从第一版就埋好埋点不要等到后面再补。因为陪诊平台的核心运营指标有几个接单响应时长、陪诊员到岗率、服务完成率、用户投诉率、复购率。这些指标如果一开始不设计后面补数据治理会非常痛苦。2.4 订单流转与状态机设计订单状态机是整个系统的灵魂。我们的状态定义可以给你直接参考状态编码状态名称前置状态说明0待支付-用户已下单未付款1待接单0已付款等待陪诊员接单2已接单1陪诊员已抢单等待履约3已出发2陪诊员前往医院途中4已到院3陪诊员已到达医院范围并打卡5服务中4陪诊员与用户会合并开始服务6已完成5陪诊员确认服务结束7已取消0/1/2用户或陪诊员取消8已售后6用户发起投诉/售后进入处理中9已完成售后8售后处理完毕有一个容易踩的坑取消订单的权限和退款规则。医疗陪诊有很强的时间属性用户预约了第二天上午9点陪诊员可能在晚上就接单并安排好了行程。如果用户在临近服务时间前突然取消陪诊员就白等了一个时段。我们的规则是服务开始前4小时以上取消全额退款4小时以内取消收取20%违约金补偿陪诊员陪诊员接单后迟到超30分钟用户可无责取消并全额退款。这些规则不是拍脑袋定的是和运营团队反复讨论后取的一个平衡值。3. 技术选型与系统架构设计3.1 前端技术选型小程序、APP、H5怎么配先说结论用户端用微信原生小程序 H5分享页陪诊员端用uni-app打包成Android和iOS双端APP管理后台用Vue3 Element Plus的Web应用。为什么用户端不直接用uni-app我个人的实操体验是微信小程序还是用原生开发最稳。uni-app确实能一套代码多端复用但小程序的性能瓶颈经常出现在复杂交互场景上比如订单动态页面的长列表渲染、地图组件的层级冲突问题用原生小程序开发至少你能在小程序的基础库升级时第一时间跟进不会被框架版本拖后腿。陪诊员端则相反真的建议用uni-app。原因很简单陪诊员端的核心功能是接单导航位置上报这些能力打包成APP之后要同时兼顾Android和iOS双端用uni-app一套代码打两个包效率会高很多。唯一要注意的是uni-app在地图组件和定位SDK上的兼容性偶尔会有坑打包前一定要在真机上反复测尤其是Android低版本的系统定位权限的适配逻辑每个厂商都不一样这个我在后面避坑部分会再详聊。管理后台就是常规的PC Web端Vue3 Element Plus完全够用不需要过度设计。3.2 后端技术栈与接口设计后端我们用的是Spring Boot MyBatis Plus MySQL Redis RabbitMQ的经典组合。选这一套不是因为它多先进而是社区资料多、招人容易、出问题能快速搜到解决方案。医疗陪诊系统本质上是一个交易撮合系统核心诉求是数据一致性和状态流转正确性Spring Boot在这个领域排在绝对的成熟度第一梯队。接口设计上有几个要点统一返回结构code、msg、data所有接口都是这样前端对接省心。鉴权体系用JWT RedisToken有效期2小时刷新Token有效期7天APP端用长期Token小程序端用短效Token静默登录。接口幂等性支付回调、用户重复提交下单请求、陪诊员重复点击接单这些场景都容易触发重复请求。我们用Redis分布式锁唯一请求号做了幂等控制。这里我展开说一下抢单场景的并发设计。陪诊订单进入待接单状态后可能同时有多个陪诊员点击接单这是一个典型的秒杀场景。我们的解决方案是Redis预扣减订单状态用setnx命令实现锁。抢到单之后异步把订单状态持久化到MySQL。抢单失败返回手慢了不显示订单已被抢这种挫败感强的文案。订单接单超时机制如果订单发布后30分钟内无陪诊员接单触发自动取消并退款给用户。这个方案实测能在不引入MQ的情况下应对初期流量等到日订单量上万再上消息队列做削峰也不迟。3.3 数据库设计要点与表结构示例数据库设计是整个系统最容易前期埋雷、后期爆炸的部分。我把核心表的思路分享一下你参考着设计就不会跑偏。用户表user核心字段user_id、openid小程序、phone、nickname、avatar、user_type1普通用户/2陪诊员、emergency_contact、emergency_phone、status。 紧急联系人字段务必加这是医疗场景的特殊需要。陪诊员表escort_user核心字段escort_id、user_id、cert_type、cert_no、service_area、service_status休息/在线接单/服务中、rating、completed_orders。 资质审核涉及身份证、健康证、无犯罪记录证明每个资质状态都要有单独的审核状态字段不能只存一个审核通过了事。服务项目表service_item核心字段item_id、item_name、item_type1陪诊/2代办/3住院陪护、price_type1按小时/2按次/3按半日、base_price、unit_price、description。 价格模型不要做成单一一口价医疗陪诊的特殊性在于会有夜间服务费、双人陪诊费、特殊病种附加费这些要设计成可叠加的费用项。订单主表order核心字段order_no唯一业务单号、user_id、escort_id、service_item_id、hospital_id、department、visit_time、status、cancel_type、refund_status、total_amount、pay_amount、create_time。 订单号我建议不要用自增ID直接给用户看业务订单号用yyyyMMddHHmmss6位随机数生成既方便查询又不会暴露平台单量。订单状态记录表order_status_log这是最容易忽略却最有价值的表。每一条订单的状态变化都要记录from_status、to_status、operator_type、operator_id、remark。后续对账、客服排查、数据统计全靠它。位置轨迹表location_track核心字段order_id、lat、lng、accuracy、create_time。陪诊员在服务过程中每30秒上报一次位置这个数据不只是给用户看位置共享也是后续发生纠纷时判断是否在服务现场的关键证据。评价表evaluation核心字段order_id、user_id、escort_id、score1-5、tags、content。评价要在服务完成后24小时内开放超过时限自动默认5星不我们做了不评价不计分的机制防止默认好评失真。佣金结算表settlement核心字段order_id、escort_id、order_amount、commission_rate、commission_amount、settle_status、settle_time。你可能会觉得表数量好像不多但真实项目里最终会有40多张表。上面列的是核心交易链路还有营销优惠券、消息通知模板、财务提现、风控黑白名单等域的表。数据库设计的原则就一条状态可追踪、金额可对账、操作有留痕。4. 关键功能的实操实现细节4.1 微信小程序登录与手机号授权微信小程序的登录流程现在和几年前完全不同最新的方案已经不建议走wx.getUserInfo了改用wx.login获取code后端拿着code到微信接口换openid和session_key。这里有一个特别重要的坑微信从2022年之后wx.getUserProfile接口在绝大部分场景下已经拿不到真实的用户头像和昵称返回的都是一张默认灰色头像和微信用户。所以如果你在网上搜到2021年之前的教程教你用wx.getUserProfile获取头像昵称那套方案现在早就废了。想拿用户头像昵称唯一合规的方式是引导用户在个人资料页手动填写或者使用微信开放能力里的头像昵称填写能力组件让用户自行选择。获取手机号的流程 现在的标准做法是用button open-typegetPhoneNumber bindgetphonenumber...但是注意从2023年之后手机号获取能力也有了新的限制——必须是企业主体的小程序且手机号组件返回的是code而不是直接的手机号后端需要用code去调微信的phonenumber.getPhoneNumber接口换取真实手机号。这个code有效期只有5分钟而且一个code只能使用一次后端一定要处理好幂等否则用户多点一次就会报错。4.2 订单创建与支付流程陪诊订单的创建比普通商品订单要复杂因为涉及到服务时间和医院科室的合法性校验。下单接口的完整校验链路服务时间校验不能下单过去时间不能跨年预约医院号源一般只放未来7-14天要设置最大可预约天数。医院科室校验维护一个平台侧的医院科室库用户只能选择库里有的科室。这个库初始数据可以通过爬取公开数据或者手动维护但运营过程中一定要有专人更新医院科室调整非常频繁。重复下单校验同一用户同一个时间段内不能创建两个订单防止恶意下单和资源冲突。金额计算基础价时长/次数价附加费生成订单快照关键订单表里要存下单时的价格快照不能后来价格变了连历史订单金额也变了。支付环节我们接的是微信支付和支付宝的native支付APP端和JSAPI支付小程序端。支付成功回调里有一个极容易被忽略的问题要校验回调里的订单金额和本地订单金额是否一致这是支付安全的基础要求防止支付串单和篡改。回调处理要天然支持幂等因为微信和支付宝都会重试回调。4.3 陪诊员接单与状态上报实现接单的并发控制前面提到了用Redis锁。这里我再补充一下陪诊员端的状态上报实现细节位置上报陪诊员端APP每30秒通过AMapLocation获取一次定位上报到后端/api/v1/location/report接口。后端把数据写入location_track表同时通过WebSocket实时推送给用户端小程序展示。WebSocket连接如果断开了要自动重连并且重连后要补推最近5分钟内的轨迹点保证用户看到的位置是连续的。状态机推进陪诊员的每一个关键动作接单、出发、到院、开始服务、结束服务其实都是后端状态机的一个合法推进事件。举个例子陪诊员点击开始服务时后端要先校验当前订单状态必须是已到院并且陪诊员和用户的距离小于100米才能允许这个操作执行。这种事件校验的模型比单纯改状态字段要可靠得多。4.4 评价系统与售后处理评价系统我们做了双向评价用户可以评价陪诊员陪诊员也可以对用户进行标签记录比如老人需要搀扶用户沟通有障碍用户经常修改时间。这个双向标签体系对平台运营极其有价值——用户的标签可以帮助陪诊员提前做好服务准备陪诊员的标签则进入了服务质量考核。售后处理的流程我建议做成工单制用户发起售后自动生成售后工单关联原订单。客服介入如果需要陪诊员提供说明系统自动给陪诊员推送工单通知并限时6小时响应。退款审批走三级流程客服初审、财务复审、超500元金额需要主管审批。退款原路退回系统记录退款流水。5. 开发避坑指南医疗陪诊系统特有的坑5.1 合规与隐私保护不是小事医疗陪诊系统接触的是用户的健康信息这属于敏感个人信息合规要求非常高。我们的做法是隐私政策单独成文在用户首次进入APP/小程序时弹窗明确告知。健康信息病情描述、诊断信息在后端存储时做加密展示给陪诊员时做脱敏处理。订单的取消/售后数据保留时间严格遵守相关要求超期自动清理。陪诊员必须签署保密协议平台保留追责权利。这些不只是法律要求也是用户信任的基础。医疗行业的用户对隐私数据的敏感度远高于普通电商用户。5.2 系统稳定性与限流设计陪诊系统的流量不像电商那样有双十一的高峰但存在明显的工作日上午高峰。医院通常在早上8点到10点迎来就诊高峰用户可以提前一天预约下单这样流量其实是分散的。但有一个特殊场景要注意——医院放号时间。很多医院的号源在固定时间点比如早上8点统一放出这时候用户会集中下单瞬时QPS会冲到日常的几十倍。如果不做限流订单服务直接被打挂是大概率事件。我们的限流策略接口层面对创建订单、支付回调、位置上报三个接口做单独的QPS限流网关层用Sentinel控制。业务层面同一用户单位时间内最多创建1个订单同一陪诊员单位时间内最多接收5个新订单通知。数据库层面订单表的分表策略按订单号做hash分表位置轨迹表按月份做分区。5.3 测试环节中那些看起来没事上线就炸的坑我这次项目踩了一个典型的坑提前分享给你微信小程序的地图组件在开发者工具里一切正常但真机上地图会覆盖其他元素导致确认按钮点不到。这是微信小程序的层级问题map组件的层级优先级太高需要用cover-view来承载覆盖在上面的按钮。这个问题在开发工具里完全复现不出来只能靠真机测试发现。还有一个坑是Android键盘弹出挤压布局。用户下单页填写地址和病情描述时Android软键盘会把底部的提交按钮顶上去导致用户看不到支付按钮。这个问题的解法是设置adjustResize并且重写软键盘监听让页面在键盘弹出时自动滚动到当前聚焦的输入框。6. 常见问题排查与实操记录6.1 常见问题速查表问题现象排查思路解决方案小程序登录失败后端拿不到openid检查appid是否配置正确code是否过期确认小程序后台的appid与后端配置一致code有效期5分钟需及时换取支付回调不成功用户已扣款但订单状态未变更查看后端日志是否有回调记录检查签名校验是否通过用微信支付官方demo验签逻辑回调处理函数要设置返回success位置不更新用户端看不到陪诊员位置Android机型后台定位权限是否被系统清理引导用户打开后台定位权限并设置前台服务通知防止进程被杀死抢单并发异常多个陪诊员同时抢同一单检查Redis锁的key和过期时间锁的key要带订单号过期时间建议3秒操作完成后主动释放小程序地图点不到地图盖住了按钮检查层级确认是原生组件问题用cover-view替换普通view承载地图上层元素订单状态不流转陪诊员点了结束服务订单没变化检查状态机校验逻辑前置状态是否符合确认当前订单状态是服务中且结束条件已满足6.2 我实际操盘过程中的三点体会第一陪诊系统真正的护城河不是技术是运营和供给。技术上的功能模块任何一个有点经验的开发团队都能在两三个月内搭建出来。但能不能持续招募到稳定的陪诊员、能不能让用户对平台产生信任、能不能把医院服务流程摸透并且形成SOP这才是决定这个项目能走多远的关键。我在开发过程中反复提醒团队功能是骨架运营才是血肉。第二价格设计需要数据验证不要拍脑袋。我们对不同城市、不同服务类型的订单数据做了对比发现一线城市的专家陪诊半日服务价格在300-500元之间而普通医院的普通陪诊每小时30-50元。如果不做分层定价只做一个一口价要么高端用户觉得不专业要么低端用户觉得太贵。第三医疗陪诊和大多数互联网产品不一样它的容错空间极小。普通电商的订单出错了退个款就好了陪诊订单如果出了问题轻则用户就医体验差重则可能耽误病情。所以我们的系统设计原则一直是宁可多一个确认步骤也不放过一个风险。每次进行操作之前都会明确提示用户确认每次状态流转都有留痕每次异常都有自动告警。这套系统的开发过程中我把上面的每一个模块都踩过一遍也优化过好几轮。目前系统已经稳定运行了大半年日订单峰值接近千单。如果你也在做类似的项目欢迎拿上面的架构和功能清单做个对照看看哪些地方可以复用哪些地方需要根据你自己的业务节奏做调整。医疗陪诊行业还在快速发展期现在把基础打牢后面才能走得更稳。