去年接了一个互联网医院预研的评估单老板让我先找开源项目做技术摸底。我翻遍几个主流代码托管平台发现一个挺有意思的现象搜索“互联网医院”出来的仓库不少但点进去要么只有一张患者端的UI空壳要么后台躺着几十张空表真正能跑通“挂号-问诊-开方-支付-取药”完整闭环的两只手数得过来。这篇文章不替某个具体项目打广告而是基于我拆解过的多个开源互联网医院系统的共性设计把它的功能模块和实现逻辑从头到尾理一遍。适合正在做互联网医院、在线问诊、预约挂号类产品预研的后端或全栈开发者也适合医疗IT公司准备做二次开发的朋友参考。看完你至少能回答清楚一个问题一套能用的开源互联网医院系统到底长什么样。1. 先建立整体认知互联网医院系统到底要覆盖多少角色与场景1.1 业务全景一个系统装下四类用户互联网医院本质上是实体医院线上服务窗口的数字化延伸而不是简单搭个在线聊天室。核心是把线下的预约挂号、看诊、开方、缴费这些流程搬到线上同时还要保证医疗合规。所以一个能称为“系统”的开源项目至少要覆盖四类用户患者小程序/H5/APP完成注册建档、实名认证、预约挂号、在线问诊、报告查询、在线支付、健康档案管理。医生Web工作站或移动端完成接诊、病历书写、处方开具、检验检查申请、患者管理、排班申请。运营和管理端管理员、药师、客服完成药品审核、排班维护、订单管理、对账、运营统计。对接方医院内网的HIS、LIS、PACS以及微信支付、短信、OSS这类第三方平台。很多人以为互联网医院系统就等于在线问诊加支付这是最大的误解。没有挂号和处方流转这两个重业务在线问诊根本撑不起一个完整系统。挂号涉及号源库存和订单状态机处方涉及药师审核和用药合规这两块才是源码里最值得读的部分。在医院里跑过的朋友都清楚这类系统最难受的不是功能多而是流程状态不能乱。患者挂了一个号医生停诊了怎么办患者支付了问诊费医生一直不接诊怎么办处方开出来了药师驳回了怎么办这些在需求文档里可能只是一句话但在代码里就是一整套状态流转和补偿逻辑。开源项目恰恰把这些逻辑写进了代码里这就是拆解价值所在。1.2 技术栈选型为什么主流开源项目都是这套组合我拆过的开源项目里技术栈高度趋同基本是下面这张表端主流选型选型理由患者端uni-app 或微信小程序原生医院场景流量入口以微信小程序为主uni-app 支持一套代码多端发布医生端/管理端Vue3 Element Plus组件丰富Element Plus 对表格、表单这类后台场景支持好后端Spring Boot MyBatis PlusJava 生态在医疗行业渗透率极高便于和 HIS 系统对接数据库MySQL 8.x社区成熟运维成本低缓存Redis号源库存扣减、会话状态、分布式锁的核心依赖消息队列RabbitMQ异步通知、延迟关单、超时退款都要靠它文件存储MinIO / 阿里云OSS存放问诊图片、检验报告、证件图片即时通讯WebSocket / Socket.IO图文问诊和视频问诊会话通道后端点选 Java 技术栈我猜很多人一开始不理解。互联网医院完全可以做成 PHP 或者 Node医院选型却普遍偏向 Java。原因很简单国内医院的存量 HIS 系统绝大多数是 Java 或 .NET 技术栈项目做二次开发的时候经常需要直接读取 HIS 的数据库或者调用接口同生态对接的阻力最小。另外 MyBatis / MyBatis Plus 这类框架在复杂 SQL 和存储过程上控制力更强适合医疗系统里大量动态查询的场景。1.3 单体多模块和微服务的取舍开源互联网医院项目里真正用微服务的其实不多大多数是单体多模块结构。这一点放在商业项目里反而是优势——单体事务好处理扣费、扣号、更新状态这些强一致性场景在一个应用里直接搞一个Transactional就完了拆成微服务以后光分布式事务就够喝一壶。医院内网部署环境普遍资源有限一台 8C16G 的服务器要跑完整个后端单体部署的维护成本也最低。有些商业化版本会拆成患者服务、医生服务、支付服务、基础服务但拆分的边界依然是按“业务域”而不是按“功能点”去拆。拆源码的时候我建议你先把它当成一个逻辑整体来看不要上来就钻进某个 Controller 里。2. 源码目录的正确打开方式从工程结构反推业务地图2.1 典型工程结构每个目录都是一个业务域开源项目的目录结构大同小异一个比较典型的布局是这样的hospital-online/ ├── backend/ │ ├── admin-server # 运营管理端服务 │ ├── doctor-server # 医生端服务 │ ├── patient-server # 患者端服务 │ └── common # 公共模块工具类、统一返回、异常处理 ├── frontend/ │ ├── patient-mp # 患者端小程序 │ └── doctor-web # 医生端Web工作站 ├── sql/ │ ├── init.sql # 全量初始化脚本 │ └── upgrade/ # 增量升级脚本 └── docs/注意这里明显是“按端拆服务”而不是“按业务拆服务”。患者端服务里既可能包含挂号也可能包含问诊和支付因为它把“患者访问的所有接口”聚合到了一起。微服务拆法则是按挂号、问诊这种业务域去拆。这两种拆法各有利弊但看源码时你必须先搞懂当前项目是哪种否则很容易在一个服务里找半天找不到某个接口。2.2 数据库脚本拆解源码的第一站我打开一个开源项目后的第一件事不是看代码而是找sql/目录下的初始化脚本。原因很简单医疗业务里大量关键信息都是沉淀在表结构和状态字段里的把核心表看懂了整个系统基本就通了一半。看表的时候有个技巧先找状态字段。订单表里有没有statusstatus有哪些枚举值这些枚举值在代码里是怎么流转的很多项目会写一个OrderStatusEnum.java打开这个枚举类比读十篇 README 都管用。2.3 三张核心主表排班、问诊、处方围绕互联网医院最核心的表就三张另外加两块明细表表名关键字段说明doctor_scheduledoctor_id、schedule_date、period、total_count、remain_count医生排班相当于号源库存appointment_orderpatient_id、schedule_id、status、pay_status、channel挂号订单核心是订单状态机consult_orderpatient_id、doctor_id、type、status、consult_start_time在线问诊单图文/视频/电话prescriptionconsult_id、status、total_amount、expire_time处方单主表只存汇总信息prescription_itemprescription_id、drug_id、usage_dosage、quantity处方明细一单多药必须拆明细表这里特别值得说的是doctor_schedule.remain_count。很多开源项目在设计时会把“号源剩余数”直接存到这个字段里用户点击挂号的瞬间执行UPDATE ... SET remain_count remain_count - 1。这在低并发下没有问题但一到专家门诊放号那种高并发场景这个字段就是热点记录会成为性能瓶颈。到底怎么改造下一章详细讲。3. 预约挂号与在线问诊两条核心业务链路的实现逻辑3.1 号源库存用 Redis Lua 做预扣减从源头避免超卖挂号的本质是一个库存系统难点在于控制超卖。号源只有 30 个系统同时来了 100 个人抢总不能卖出 35 个号出去。直接在 MySQL 里做UPDATE doctor_schedule SET remain_count remain_count - 1 WHERE id ? AND remain_count 0确实能防超卖但问题是大并发下这个行锁会让数据库成为热点。成熟的做法是 Redis 预扣减。放号时把号源数量同步到 Redis用户点下单时用一段 Lua 脚本原子扣减-- KEYS[1]: schedule_id 对应的号源 key -- KEYS[2]: 用户当日挂号次数限制 key可选 local stock tonumber(redis.call(GET, KEYS[1]) or 0) if stock 0 then return 0 end redis.call(DECR, KEYS[1]) return 1这段脚本通过 Redis 单线程执行保证原子性扣减成功后再去创建订单订单创建成功后再异步把剩余号源写回 MySQL。这样数据库的压力被降到了最低Redis 的 QPS 支撑量级是 MySQL 远远比不上的。但这里有个坑Redis 扣了号订单没创建成功号就丢了。所以必须配套一个补偿任务定期扫描那些“已扣号但订单未完成”的中间状态数据把号源回补回去。开源项目里这块做得好的不多这是二次开发时最值得你重点检查的环节。3.2 挂号订单的状态机八种状态要闭环挂号订单的状态设计是互联网医院最见功力的地方。一个典型的状态枚举大概长这样状态值含义触发动作WAIT_PAY待支付下单成功锁定号源PAID已支付支付回调成功USED已取号/已就诊扫码取号或医生接诊FINISHED已完成诊疗结束归档CANCELED已取消用户主动取消TIMEOUT_CLOSED超时关闭超过支付时限系统自动取消REFUNDING退款中停诊、退号触发REFUNDED已退款退款完成号源回补这里最核心的逻辑是超时关闭。用户下了单但一直不支付号源不能一直占着。常见方案是用 RabbitMQ 延迟队列订单创建后投递一条延迟消息比如延迟 30 分钟消费端检查订单状态如果还是WAIT_PAY就把订单改成TIMEOUT_CLOSED同时异步把 Redis 和 MySQL 里的号源回补。你读源码的时候会看到类似OrderTimeoutConsumer这样的类注意看它的消息投递和消费逻辑这里最能看出作者对消息可靠性的把握。消息丢了怎么办消费失败怎么办有的项目还会加一张mq_message表做本地消息表投递前先写库消费成功后标记这是常规的可信做法。3.3 在线问诊从接诊池到电子处方在线问诊单的状态流转比挂号还要多一环完整流程大概是这样患者选择医生选择图文/视频问诊创建consult_order状态WAIT_PAY。支付成功订单进入医生的接诊池状态变成WAIT_RECEIVE。医生端界面出现待接诊的订单点击“接诊”状态变成CONSULTING。患者和医生建立 WebSocket 会话互相发送图文、语音、视频消息。医生写病历、下诊断、开处方处方进入药师审核。患者确认处方支付药费订单状态变成FINISHED。药品进入配送或到店自取环节。为什么问诊单也要“接诊”这个动作这是很多业务新手容易忽略的点。一方面医生可能正在看别的病人需要一个明确的“接下一位”的动作另一方面是为了防止医生挂机不处理导致患者无限等待。所以问诊单一般会有超时未接诊自动退款的机制。注意看代码里ConsultTimeoutConsumer和退款逻辑是怎么配合的。WebSocket 会话本身基本用的是 Netty 或者 Spring 自带的 WebSocket 模块。消息格式一般有type字段区分text/image/video/system系统消息用来推送“医生已接诊”“处方已开具”这类状态提醒。医疗场景下的聊天记录有存档要求所以消息不能阅后即焚必须落库。3.4 处方审核与支付链路的衔接处方模块是互联网医院和普通电商系统最大的区别之一。处方主表prescription保存医生、问诊单、审核药师、总金额、处方状态明细表prescription_item保存具体药品和用法用量。一张处方多个药品必须拆明细表这是标准的建模方式谁把药品塞成一个 JSON 字段谁后面就会后悔。处方状态一般是这样UNSUBMITTED医生起草 -PENDING_REVIEW已提交待审核 -REVIEWED药师审核通过 -DISPENSING药房配药 -FINISHED患者取药/签收。如果药师审核不通过会变成REJECTED还要记录驳回理由。处方支付和问诊支付一般不混在一起。问诊费是服务费药费是药品费用两笔钱分属不同账单。开源项目里常见做法是order表带一个biz_type字段区分问诊单、挂号单、处方单但每类业务又有自己的业务表。你拆源码时理清“支付订单表”和“业务订单表”之间的关系是理解整个资金链的关键。4. 权限、幂等与消息推送几个隐蔽但决定成败的设计细节4.1 RBAC 与数据权限医生只能看到自己患者的记录拿一套开源项目看权限设计我建议直接看它的数据库权限表和拦截器。用户-角色-权限三张基础表是标配难点在数据权限。医生的账号登录后接口返回的患者列表不能是全医院的患者只能是这个医生自己接诊过的患者。这就需要在 SQL 层面做数据隔离。常见的实现方式是 MyBatis 拦截器在 SQL 执行前根据当前登录用户的角色自动拼接条件。比如医生角色自动拼AND doctor_id 当前登录用户ID药师角色拼AND review_status 待审核管理员角色不加限制。这种实现方式的优点是业务代码无侵入缺点是排查问题不方便因为 SQL 是动态拼接的你得把拦截器的日志打开打印出最终执行的 SQL。这里提供一个排查顺序先看拦截器、再看参数解析器、最后看RequiresPermissions这类注解权限漏洞多数出在“接口忘了加注解但能查到数据”。4.2 幂等设计支付回调和重复提交怎么防医疗系统的资金链路涉及挂号费、问诊费、药费任何一笔钱的重复扣要么让患者投诉要么让医院对不上账。幂等设计是硬指标。前端置灰防重复点击那只是第一层。后端必须有兜底。常规做法是维护一张幂等表或者用业务订单号做唯一约束。支付回调这块尤其重要微信、支付宝的回调在没有收到成功应答时会按策略重复通知多次。处理回调的方法很简单回调接口先执行INSERT IGNORE INTO pay_notify_log(order_no, transaction_id)。如果插入影响行数为 0说明这笔通知重复了直接返回成功。如果插入成功再执行业务更新。这比用 Redis 分布式锁更稳妥因为数据库的唯一索引是真正的“最后一道防线”不会有锁超时和缓存丢失的问题。拆源码时看支付回调方法里有没有这种幂等处理基本能判断代码作者的工程经验。4.3 问诊消息的存储与推送图文问诊产生的聊天记录数据量远大于挂号订单而且持续增长。多数开源项目不会把聊天消息塞进 MySQL 核心库而是独立到 MongoDB 或者专用的消息表。如果只能用 MySQL至少也应该按问诊单 ID 分表否则半年后消息表就是一张超大表查询性能直线下降。消息推送链路是另一块容易出问题的。患者和医生不一定同时在线WebSocket 断了以后消息怎么补开源的实现一般靠两招一是消息表里标记read_status离线用户上线后拉取未读消息二是通过小程序订阅消息或短信做离线通知。这块功能简单但代码写得好不好差别很大建议重点看“断线重连后的消息补偿”逻辑很多项目会在这一环漏消息。4.4 敏感信息脱敏与操作日志医疗系统最敏感的资产是患者隐私。成熟项目会在返回前端数据时统一做脱敏手机号保留前 3 位和后 4 位身份证号只显示前 6 位病历详情只有授权医生可看。实现方式通常是后端序列化阶段加脱敏注解比如SensitiveField(type SensitiveType.MOBILE)统一出口处理。另外一个容易被忽视的是操作日志。谁在什么时间修改了哪个患者的处方必须在系统里留下痕迹。我见过某个项目的做法是给处方主表加了个update_logJSON 字段每次变更把旧值和新值都推进去这种方案简单但查询困难。建议关注代码里有没有独立的operation_log表以及审计切面这是医疗合规对系统产生的硬需求。5. 本地部署与二次开发避坑实际动手时最容易翻车的六个问题5.1 环境版本对不上启动三分钟报错半小时拆源码最大的挫败感往往不是看不懂代码而是项目在别人电脑上能跑在自己电脑上报一堆错。版本坑集中在四件套JDK 版本、MySQL 版本、Redis 版本、RabbitMQ 版本。我建议按这个清单去对齐环境依赖建议版本参数JDK8 或 11看项目pom.xml里java.versionMySQL8.0.x注意 utf8mb4 字符集Redis6.x默认端口即可RabbitMQ3.x启用rabbitmq_management插件方便看队列Nacos2.x如果项目注册中心用了它MinIO最新稳定版本地可以用MINIO_ROOT_USER等环境变量看启动报错日志时前 30 行往往没用要往后翻到有Caused by的位置。数据库连不上、Redis 拒绝连接、RabbitMQ 虚拟主机找不到是三类高频问题基本都出在配置文件和环境版本上。5.2 增量脚本和全量脚本傻傻分不清开源项目的 SQL 脚本有两种命名风格。一种叫init.sql是全量数据库脚本可以直接重建整个库另一种是一堆带版本号的文件如V1.1.0.sql、V1.2.0.sql这是增量升级脚本。拿到项目后如果数据库里有残留数据而你自己不清楚版本最稳妥的做法是重建一个全新库然后按顺序把全量脚本和增量脚本依次执行。这里要特别提醒不要在一个已有数据的库上乱跑增量脚本可能出现字段重复和索引冲突。5.3 第三方密钥和开关没配置支付流程直接卡死短信、支付、OSS、公众号这些第三方能力都依赖密钥。很多项目在未配置时会直接抛异常或者启动失败。本地联调时有两个对策检查配置文件中是否有 mock 开关。有的项目支付模块支持 mock 模式不用真实密钥也能走通回调。如果项目没有 mock 开关可以自己写一个测试回调的接口模拟第三方回调数据结构。这块是最容易被忽略的。很多初学者跑起来项目以后卡在“支付成功”这一步就是因为没有真实的微信支付商户号回调进不来。正确姿势是先去读支付模块的NotifyController看它需要哪些参数然后自己构造一个 HTTP 请求模拟回调。5.4 排班同步开源项目里最薄弱的环节绝大多数开源项目的排班是管理员后台手动创建的而不是从实体医院的 HIS 系统自动同步。这意味着拿到项目做真实落地时排班模块基本要重写。改造方向很明确定义号源同步接口定时从 HIS 拉取排班数据再写回本地排班表。接口可以设计成这样public interface ScheduleSyncService { ListDoctorScheduleDTO pullFromHIS(Date startDate, Date endDate); void applySchedule(ListDoctorScheduleDTO schedules); }pullFromHIS做数据拉取和转换applySchedule做差量更新。差量更新要注意已经有人挂号的排班不能直接删只能做冲突标记并触发停诊流程。这个逻辑是整个排班改造的重中之重建议读源码时优先找排班 Service 的更新方法看有没有处理“已预约”情况的代码。5.5 边界业务不能漏停诊、替诊、黑名单业务边界是最容易在二次开发里被遗漏的。常见的有三个停诊医生临时停诊已挂号患者要批量通知并自动退款号源要回补涉及多个模块联动。替诊原医生停诊后安排同科室同级别医生替诊是直接替号还是重新分配需要业务规则。黑名单恶意占用号源却不付款的用户要不要限制其后续挂号限制逻辑写在订单模块还是用户模块这些内容如果源码里没有就要在你的改造文档里作为独立需求列出。我见过很多项目上线后第一个投诉就是停诊通知没到位患者在门诊白跑一趟。5.6 我推荐的二次开发顺序基于我的实操经验拿下一套开源项目后建议按这个顺序动手本地把项目完整跑起来前后端都能登录。打开数据库看核心表和状态枚举。用测试账号在患者端走一遍完整流程挂号-支付-问诊-开方-支付-取药。打开调试日志把关键接口的请求和响应打出来对照代码理解流程。确定要改的需求点先动 Service 层再动 Controller最后动前端页面。很多人习惯一上来就读代码不从业务流程走一遍结果花了三天还没建立上下文。先“走流程”再“读代码”效率翻倍。6. 开源项目的选择标准什么样的互联网医院源码值得拿来改6.1 三个评估维度完整度、代码质量、活跃度不是所有挂着“互联网医院”名头的仓库都值得你花时间。我一般用三个维度过滤维度具体检查点业务完整度有没有挂号、问诊、处方、支付、药师审核、排班状态机是否闭环有没有药师端和管理后台代码质量是否分层是否有统一异常处理核心状态流转是否集中在一个 Service 里有没有事务注解有没有测试代码活跃度star 数只能参考重点看最近一次提交时间、issue 是否有人回复、文档是否齐全有些项目 UI 做得漂亮后端却只有一个main方法直接操作数据库这种项目改造起来的成本比重写还高不建议选。6.2 我的取舍经验开源系统是“框架参考”不是“成品”如果你所在的团队没有医疗行业经验我建议用开源项目做底子可以省掉大量从零设计业务状态机的时间。如果团队本身有 HIS 开发和医院实施经验那开源项目更适合做表结构和权限设计的参考业务规则还是要结合医院实际流程来改因为不同地区、不同等级的医院流程差异相当大。另外要注意许可证。很多医疗相关的开源项目使用 Apache-2.0 或 MIT 协议商用相对友好但少部分使用了 GPL 类协议这意味着如果你基于它做二次开发并对外分发就要考虑开源义务。落地前花十分钟看一下 LICENSE 文件这十分钟能帮你省掉后续法务的大麻烦。最后说点个人体会。拆完这几个项目我最大的感受是开源互联网医院系统的价值不在于“能跑”而在于它把医疗业务里那些最容易被忽略的边界写成了可以一行行读的代码。号源锁、超时退款、处方审核、数据脱敏、幂等回调这些很多商业系统里都藏着掖着的东西在开源项目里你能直接看到实现。即使你最终不做医疗项目预约挂号里的 Redis 预扣减和状态机设计也值得静下心来读一遍。我建议你按先表结构、再 Service、最后 Controller 的顺序去拆这个顺序能帮你省掉一半时间。