聊到“医院挂号预约管理系统”可能很多人第一反应是这不就是一张预约表加上增删改查吗去年我帮一个街道卫生服务中心做这套系统时也差点这么想。等到真正调研完现场流程又动手用ThinkPHP和Laravel各实现了一版之后才发现真正的坑不在CRUD而在号源并发、状态流转和排班规则上。这篇文章就把整个从设计到落地的过程整理出来包含技术选型思路、表结构设计、防超卖方案以及部署阶段踩过的一些细节希望能给正在做同类系统的人一些参考。如果你是要毕业设计、外包项目或者自己所在的小型医疗机构想摆脱纸质排班和Excel登记这篇文章都适用。我会尽量把“为什么这样做”讲清楚而不只是丢几段代码。因为这类系统的核心难点从来都不是代码本身而是怎么把混乱的线下规则翻译成一套严谨的线上状态机。1. 为什么同时研究ThinkPHP和Laravel先想清楚框架选型再动手写代码1.1 两个框架在项目里的真实分工标题里同时出现“ThinkPHP”和“Laravel”不是随手把两个热门词拼在一起。我实际经历是项目启动时那边机房跑着一个用ThinkPHP 5.1写的老预约系统功能极其简陋但稳稳定定用了三年新需求要加多科室排班、在线支付、微信通知大家都倾向于重写。问题就来了继续用ThinkPHP还是一步到位换Laravel我当时的做法是把两套框架各写了一个可运行的原型跑同一份数据库脚本、同样的业务规则然后对比开发体验、部署成本和后期维护难度。ThinkPHP的优势非常明显文档全是中文上手快随手一写就能跑特别适合一个人快速交付而且老系统就是用它写的很多公共函数和SQL习惯可以无缝迁移。Laravel这边的优势则需要用几天才能感受到中间件机制让权限校验变得异常干净Eloquent的模型关系让排班和预约的查询少写大量JOIN队列和事件系统更是处理消息通知的利器。1.2 同样是MVC差距比想象中大很多初学者以为换框架只是换个写法其实两者的编程思维差异很大。以数据库操作为例ThinkPHP 5.1默认用Db::table()写查询构造器字段用字符串数组业务逻辑可以全部堆在控制器里反正也能跑Laravel则更倾向于你先定义Doctor模型、ScheduleSlot模型然后用whereHas、with这类方法去做关联查询代码层从控制器拆到了Service层甚至Action类里。这种差异在开发前两周不明显一旦功能增加到五六十个接口差异就出来了。ThinkPHP版本的控制器会慢慢变成一千多行的“胖控制器”而Laravel版本靠着Model关系和三五个核心Service维护起来反而轻松。所以我最后的结论是如果整个项目就我一个人维护、交付周期极短选ThinkPHP没问题如果这个系统要持续迭代两年以上Laravel更值得投入。1.3 我列过一张对比表供你参考对比项ThinkPHP 5.1/6.0Laravel 8/9/10路由定义路由文件控制器方法名绑定路由文件控制器方法支持分组和中间件数据库操作查询构造器为主ORM较弱Eloquent ORM完善模型关系好用权限校验可自定义中间件但默认弱中间件Gate策略结构清晰队列任务内置Queue功能基本够用成熟的事件队列体系重试/延迟很方便定时任务需要自己写crontabScheduler调度器schedule:run统一管理模板引擎内置ThinkTemplate默认Blade也可换成别的中文生态原生中文文档社区中文资料多中文社区逐年丰富但很多问题要查英文如果你现在还在纠结选哪个我建议别光看技术对比先问一句谁负责后期维护如果接手的人只懂ThinkPHP强行上Laravel只会增加沟通成本。技术选型没有绝对的对错只有适合不适合团队现状。2. 从就医流程倒推系统边界挂号系统的功能拆分与角色权限设计2.1 先把线下流程画出来再谈功能做这类系统最容易犯的错是一上来就画表结构。我的习惯是先把线下流程完整走一遍把所有角色和动作列出来再倒推系统边界。以我做的这个卫生服务中心为例患者到院后的完整链路是这样的预检分诊→选择科室→选择医生→选择时段→挂号缴费→候诊签到→医生叫号→就诊→开具检查或处方→离院。这套流程里真正需要线上系统支撑的节点其实是“选择科室→选择时段→挂号缴费→签到候诊”后面就诊环节由医生工作站自己的系统负责我们不做越界的事。这个边界的确定非常重要。很多做挂号系统的人想顺手把电子病历也做了结果半年都交付不了。我当时明确跟需求方讲本系统只覆盖“预约”和“挂号”两个主流程以及支撑这两个主流程所需的排班、医生管理、通知和统计功能。前后端所有需求都围绕这个边界展开其他需求一律记录到“二期”清单里。2.2 角色权限四种身份四种视图系统一共四类角色权限划分必须从一开始就定清楚角色核心权限典型操作患者注册登录、查询科室医生、预约/取消预约、在线支付/退费通过小程序或公众号完成前台收银替患者建档、现场挂号、修改号源、处理退号使用PC端前台界面科室管理员维护本科室医生信息只限本科室数据超级管理员系统全量配置科室、医生、排班模板、统计报表使用管理后台权限模型我用了经典的RBAC角色绑定权限组用户绑定角色。值得一提的细节是Laravel端我用了自带的路由中间件配合can()方法去校验权限在控制器方法里基本上只需要一行代码ThinkPHP端则是自己封装了一个权限中间件框架本身没给现成的需要写些逻辑。这里确实体现了Laravel在这方面的优势。还有一个容易被忽略的权限点数据范围权限。同样是“查看医生列表”患者看到的应该是全部出诊医生科室管理员看到的只能是自己科室的医生超级管理员能看到所有科室。这个数据范围不能用同一个接口解决我最终是分成/api/doctors和/admin/doctors两套接口避免在业务层写一堆if判断角色。2.3 功能清单成型后工作量就清晰了做完流程梳理和角色划分之后功能清单基本就定下来了用户注册登录、科室管理、医生管理、排班模板管理、排班实例生成、预约下单、订单支付/退款、取消预约、签到叫号、停诊通知、爽约统计、后台日/月报表。列出来之后我自己都倒吸一口气单子不小但每个模块的边界都很清晰排期也就有了依据。这里我的经验是功能清单必须写到“动作级”比如“排班模板管理”要拆成新增模板、修改模板、复制上一周模板、批量生成实例这几个动作不然排期一定会失控。3. 数据库怎么设计才能撑住号源、医生排班和预约状态流转3.1 核心表结构六张表打底再逐步扩展数据库设计是整个系统的地基。我最终用的表结构可以浓缩成六张核心表表名关键字段作用usersid, name, id_card, phone, password患者与后台管理员共用一张表type区分角色departmentsid, name, parent_id, sort科室树形结构支持二级科室doctorsid, department_id, name, title, introduction医生档案关联科室schedule_templatesid, doctor_id, week_day, start_time, end_time, capacity, status每周排班模板schedule_slotsid, doctor_id, date, start_time, end_time, capacity, remaining, status某天某个医生某个时段的号源实例appointmentsid, slot_id, user_id, appointment_no, status, paid_at, cancelled_at预约订单记录完整状态流转这里核心的设计思路是“模板与实例分离”。schedule_templates管规律性排班比如某医生每周一三五上午出诊schedule_slots管具体某一天的号源。系统每天凌晨定时任务根据模板批量生成未来14天的号源实例如果遇到临时停诊直接停用某一天的schedule_slots即可不会影响模板。3.2 排班生成与号源数据的关系为什么要把号源拆成独立表而不是在doctors表里存一个剩余号数因为剩余号是随时间变化的且每个时段的号源相互独立。医生周三上午有20个号下午有15个号如果只存一个总量根本没法判断患者约的是上午还是下午。拆成schedule_slots之后每次预约只针对某一个具体时段实例做扣减逻辑就非常直白。生成排班实例的伪逻辑大概是这样找到未来日期范围内所有启用状态的模板排除节假日停诊标记然后批量创建schedule_slots记录remaining初始等于capacity。这个定时任务在Laravel端用Schedule实现在ThinkPHP端则写了一个命令行脚本挂crontab每天早上五点执行一次。生成完后要做一次幂等保护也就是同一天同一个医生同一个时段只能存在一条记录避免重复生成导致号源翻倍。3.3 预约状态机准确地说它就是系统的灵魂预约订单的状态设计非常关键我最开始只设计了“已预约/已取消”两个状态结果上线两天就发现问题患者预约后没付费怎么办到院没签到怎么算医生停诊导致订单要自动变更为取消怎么办后来我把状态扩展成完整的状态机状态值含义允许的下一状态pending待支付预留号源paid, cancelled, expiredpaid已支付/待就诊arrived, cancelled, no_showarrived已签到/候诊中in_progress, completein_progress就诊中completedcompleted已完成终态cancelled已取消终态no_show爽约终态每个状态迁移都会写一条appointment_logs记录包含操作人、动作、时间、备注。这个日志表看着不起眼后期查纠纷、对账、统计爽约率时帮了大忙。而且状态迁移我统一封装在AppointmentService里任何入口小程序、前台、定时任务都走同一个服务方法绝不直接在控制器里改状态字段。3.4 字段类型与索引这些细节别省事字段类型上有个经验appointment_no这种业务单号用varchar(32)并加唯一索引方便按单号查询金额统一用decimal(10,2)绝不用float手机号、身份证号要加索引但不加唯一约束因为确实存在同一个监护人给多个家属挂号的情况。时间字段统一用timestamp别混用datetime不然跨时区或者做日统计的时候会想哭。索引方面appointments表上一定要对slot_id和user_id分别建索引因为高频查询就是“查某个号源被约了多少”和“查某用户的历史预约”。schedule_slots表则对doctor_id date建联合索引排班查询基本都是这个组合。我上线后最严重的一次慢查询就是没给appointments.slot_id加索引导致的200毫秒查询直接飙到2秒加上之后恢复了正常。4. 预约冲突与超卖问题高并发下的号源扣减与防重实现4.1 超卖是怎么发生的一次并发请求的经典事故假设某个时段只剩最后1个号源两个患者同时点击“确认挂号”。如果没有并发控制程序会先查出remaining1A请求判断大于0执行扣减B请求也查出了remaining1同样判断大于0同样执行扣减。最终数据库里也可能出现两条预约记录但号源已被扣成负数——这就是典型的超卖。很多项目会在前端加“按钮点击后置灰”、在接口层加“用户五分钟内不能重复提交”但这两招都防不住并发。前端防御只是降低概率真正的可靠性必须落在数据库层面。我的方案是三层防线数据库事务 行级锁 前端幂等键。4.2 方案对比乐观锁、悲观锁、Redis原子操作方案实现方式优点缺点乐观锁更新时带version条件失败重试并发性能好冲突多时用户体验差悲观锁SELECT ... FOR UPDATE逻辑简单绝对可靠锁等待可能造成连接堆积Redis扣减DECR原子操作性能极高需要处理Redis与MySQL的一致性问题具体场景不同选择也不同。挂号系统的号源扣减频率远低于秒杀单时段一般就几十个号并发压力有限所以我最后选择了悲观锁加事务。这样最保险逻辑也最容易给需求方讲明白。4.3 Laravel实现事务加行锁代码量其实很少public function createAppointment(array $data) { return DB::transaction(function () use ($data) { $slot ScheduleSlot::query() -where(id, $data[slot_id]) -where(remaining, , 0) -lockForUpdate() -first(); if (!$slot) { throw new BusinessException(该时段号源已约满); } $slot-decrement(remaining); return Appointment::create([ appointment_no $this-generateOrderNo(), slot_id $slot-id, // ... 省略其他字段 status pending, ]); }); }重点是lockForUpdate()它会对命中行加排他锁第二个事务在第一个事务提交前会一直等待这样就不会出现两个请求同时读到remaining1的情况。where(remaining, , 0)加了一重数据库层面的兜底哪怕业务代码出bug也不可能把剩余号扣成负数。DB::transaction确保扣减号和创建预约记录要么同时成功要么同时回滚。4.4 ThinkPHP实现同样的思路语法略有区别public function createAppointment($data) { return Db::transaction(function () use ($data) { $slot Db::name(schedule_slot) -where(id, $data[slot_id]) -where(remaining, , 0) -lock(true) -find(); if (!$slot) { throw new BusinessException(该时段号源已约满); } Db::name(schedule_slot) -where(id, $slot[id]) -dec(remaining) -update(); return Db::name(appointment)-insertGetId([ appointment_no $this-generateOrderNo(), slot_id $slot[id], // ... status pending, ]); }); }ThinkPHP 5.1里对应的是lock(true)配合Db::transaction()就可以实现行锁。要注意的是lock(true)必须配合find()使用如果先查出数据再调lock()锁可能没生效。这个坑我实际踩过因为TP的链式查询里lock和查询条件的位置会影响SQL拼接建议写完后打印一下SQL日志确认有FOR UPDATE。4.5 防重不止后端幂等键和取消后的号源释放除了行锁我还给前端加了幂等键机制。用户点击“确认挂号”时前端生成一个client_token后端拿这个token在Redis里做SETNX重复提交同一个token直接返回“请勿重复操作”。这个token同时也能挡住部分脚本刷接口的行为。取消预约后的号源释放也是一个容易出错的地方。我规定只有pending和paid状态的订单可以取消取消时状态置为cancelled同时把对应schedule_slots的remaining加回来并且给用户退款如果已支付。这两个动作同样放在一个事务里避免出现订单已取消但号源没恢复的脏数据。实测中我用压测工具模拟了200个并发请求同时抢同一个只剩10个号的时段最终预约成功的记录恰好是10条没有一条重复没有负号源数据库一致性没问题。这个结果验证了“事务行锁”方案在当前量级下完全够用没必要为了炫技引入复杂的Redis扣减方案。5. 消息通知、支付对接与行政后台容易被低估的配套模块5.1 预约成功和停诊通知设计一个可插拔的通知通道挂号系统逃不掉消息通知最基础的两个场景是“预约成功提醒”和“医生临时停诊提醒”。通知渠道至少包括短信、公众号模板消息或小程序订阅消息。一开始我把通知逻辑直接写在预约Service里后来发现每次加一个渠道就要改业务代码非常痛苦。重构后我抽象了一个通知接口interface NotificationChannel { public function send(string $to, string $title, string $content): bool; }短信渠道、微信渠道、站内信渠道分别实现这个接口业务端只调Notification::send()。Laravel自带成熟的Notification组件可以直接扩展ThinkPHP版本我是在app/Service/Notification目录下手动实现的同样逻辑。这个抽象做完之后新增一个“APP推送”只需要加一个实现类业务代码一行不用动。5.2 挂号费支付与退款回调处理是重中之重支付模块不是自己做支付而是对接第三方统一支付接口。流程是用户提交预约且状态为pending后端生成支付单号并返回支付参数用户完成支付后第三方回调通知后端后端在回调里校验订单信息把订单状态从pending改为paid同时更新号源状态。这里最容易出问题的是回调处理必须做到“一次且仅一次”的语义校验。我会判断回调单号是否存在、订单状态是否已经为paid如果已经是paid就直接返回成功不再重复改状态。退款则走反向流程用户取消订单若已支付则调用退款接口退款回调成功后把状态标记为refunded。千万别在取消订单的路上直接改状态而不管退款结果否则会出现“订单显示已取消但钱没退”的客诉。5.3 爽约规则与黑名单设计越简单越好用爽约的定义是患者预约成功且已签到状态为paid但在就诊时段结束后仍未到院签到。为了避免运营规则太复杂我用的是最简单的策略就诊日次日零点跑定时任务扫描paid状态且就诊时间已过的订单标记为no_show一个月内爽约两次进入黑名单限制未来一周不能在线预约。只有线上下单才参与爽约判定前台人工挂号的订单不参与。这个规则在需求确认时和一线的护士长反复对齐过因为“哪种算爽约”的界定他们最清楚。我也建议后来者在这一步多花时间跟运营同事确认技术本身不复杂但规则理解偏差会导致上线后各种客诉。5.4 后台报表管理者真正关心的几个数字行政后台除了基础CRUD最不能缺的是统计报表。我做了三张核心报表科室号源使用率报表某科室某天放号多少、已约多少、使用率百分比、医生出诊工作量报表某医生周期内接诊人数、平均每人时长、患者爽约率报表。这些报表的查询条件都很简单真正麻烦的是数据口径比如“已挂号数”要不要剔除取消订单“使用率”分母是放号数还是可预约天数。我的建议是开发时先把口径写在代码注释里不然三个月后你自己都忘了当初怎么算的。技术实现上这类统计报表不建议实时跑大聚合SQL我是每天晚上用定时任务把当天的统计结果预聚合到一张daily_stats表里后台直接查表响应时间基本都在100毫秒以内。6. 从本机到服务器部署、日志与性能调优的实操记录6.1 部署环境与基础架构最终上线环境用的是Nginx PHP-FPM MySQL 5.7 Redis 6.0服务器配置不高2核4G但支撑卫生服务中心一天几百号的预约完全没有压力。Nginx里最关键的是伪静态配置Laravel和ThinkPHP的入口都在public目录需要把请求都转发到index.php。Laravel下面这段配置是最常用的location / { try_files $uri $uri/ /index.php?$query_string; }ThinkPHP的伪静态略有不同但思路一致。另外一定要确认PHP-FPM的upload_max_filesize、memory_limit这些参数别等上传证件照片报错的时候才想起来调。6.2 Laravel部署最容易翻车的三个细节第一storage目录权限。storage和bootstrap/cache必须让PHP-FPM进程有写权限我吃过没配权限导致日志写不了、页面白屏的亏。第二php artisan config:cache之后如果改了.env文件没重新缓存配置会不生效而如果改完.env不清理缓存反而可能让老配置继续续命这个细节很容易迷惑人。第三队列监听。通知和回调里用到的队列任务必须保证php artisan queue:work常驻运行否则消息通知会积压。我用的是supervisor托管队列进程比直接用nohup挂后台靠谱得多。6.3 ThinkPHP部署runtime权限与日志切割ThinkPHP端部署相对简单但runtime目录权限是同样的坑一定要确保可写不然各种缓存、日志都会出问题。另外ThinkPHP的日志是单文件追加时间久了文件会非常大最好在运维层面做一下按天切割或者定期清理不然磁盘很容易被撑满。我在上线前就把日志级别调整成了record只记录error级别避免generate级别刷出海量调试日志。6.4 性能调优慢查询日志与Redis缓存热点数据上线稳定后我做了一轮性能排查。打开MySQL慢查询日志发现大部分耗时SQL集中两类一类是后台报表查询通过预聚合表解决了另一类是首页科室列表和医生列表本身查询不慢但每次请求都查数据库白白浪费时间。解决方案是加Redis缓存科室列表缓存到Rediskey为departments:all排班变更或医生信息修改后主动删除缓存。医生排班列表则按“科室日期”组合成key比如schedule:department:5:2025-01-10缓存有效期设为五分钟或排班变更时失效。这个优化做完接口平均响应时间从180毫秒降到了30毫秒左右效果非常明显。6.5 安全加固这些坑基本每个医疗系统都会遇到最后说安全围绕的是几个真实发生过的攻击场景。接口层面所有需要登录的接口都校验了用户身份避免水平越权——患者A不能通过改URL里的ID去查看患者B的预约记录。提交预约时校验了CSRF Token尤其是后台管理界面。前端登录加入了图形验证码防止脚本批量注册。支付回调接口做了签名验证并且对回调IP做了白名单校验避免伪造回调。还有一点容易被忽视敏感信息脱敏。身份证号、手机号在列表接口中默认不返回只有本人查看详情或后台管理员操作时才展示完整信息。这些虽然是常识但在这个行业里安全问题从来不是技术多高深的问题而是有没有意识去做的问题。整套系统从开始调研到上线前后花了大概两个半月。回头看最值得分享的经验不是某个具体函数怎么写而是一个认知预约系统的灵魂是状态机和并发控制而不是页面漂不漂亮。把状态流转、号源扣减这些底层逻辑想透了不管用ThinkPHP还是Laravel写出来的代码都不会差到哪里去。希望这篇记录能帮你少踩几个坑。最后再提一句如果真正要上线医疗业务系统合规要求会比普通系统严格得多这些环节建议在做需求调研阶段就主动向相关方确认清楚。 
长河君 · 2026/10/21 8:48:11 · 阅读 1.2k 医院挂号预约系统实战：框架选型、数据库设计与防超卖方案
聊到“医院挂号预约管理系统”可能很多人第一反应是这不就是一张预约表加上增删改查吗去年我帮一个街道卫生服务中心做这套系统时也差点这么想。等到真正调研完现场流程又动手用ThinkPHP和Laravel各实现了一版之后才发现真正的坑不在CRUD而在号源并发、状态流转和排班规则上。这篇文章就把整个从设计到落地的过程整理出来包含技术选型思路、表结构设计、防超卖方案以及部署阶段踩过的一些细节希望能给正在做同类系统的人一些参考。如果你是要毕业设计、外包项目或者自己所在的小型医疗机构想摆脱纸质排班和Excel登记这篇文章都适用。我会尽量把“为什么这样做”讲清楚而不只是丢几段代码。因为这类系统的核心难点从来都不是代码本身而是怎么把混乱的线下规则翻译成一套严谨的线上状态机。1. 为什么同时研究ThinkPHP和Laravel先想清楚框架选型再动手写代码1.1 两个框架在项目里的真实分工标题里同时出现“ThinkPHP”和“Laravel”不是随手把两个热门词拼在一起。我实际经历是项目启动时那边机房跑着一个用ThinkPHP 5.1写的老预约系统功能极其简陋但稳稳定定用了三年新需求要加多科室排班、在线支付、微信通知大家都倾向于重写。问题就来了继续用ThinkPHP还是一步到位换Laravel我当时的做法是把两套框架各写了一个可运行的原型跑同一份数据库脚本、同样的业务规则然后对比开发体验、部署成本和后期维护难度。ThinkPHP的优势非常明显文档全是中文上手快随手一写就能跑特别适合一个人快速交付而且老系统就是用它写的很多公共函数和SQL习惯可以无缝迁移。Laravel这边的优势则需要用几天才能感受到中间件机制让权限校验变得异常干净Eloquent的模型关系让排班和预约的查询少写大量JOIN队列和事件系统更是处理消息通知的利器。1.2 同样是MVC差距比想象中大很多初学者以为换框架只是换个写法其实两者的编程思维差异很大。以数据库操作为例ThinkPHP 5.1默认用Db::table()写查询构造器字段用字符串数组业务逻辑可以全部堆在控制器里反正也能跑Laravel则更倾向于你先定义Doctor模型、ScheduleSlot模型然后用whereHas、with这类方法去做关联查询代码层从控制器拆到了Service层甚至Action类里。这种差异在开发前两周不明显一旦功能增加到五六十个接口差异就出来了。ThinkPHP版本的控制器会慢慢变成一千多行的“胖控制器”而Laravel版本靠着Model关系和三五个核心Service维护起来反而轻松。所以我最后的结论是如果整个项目就我一个人维护、交付周期极短选ThinkPHP没问题如果这个系统要持续迭代两年以上Laravel更值得投入。1.3 我列过一张对比表供你参考对比项ThinkPHP 5.1/6.0Laravel 8/9/10路由定义路由文件控制器方法名绑定路由文件控制器方法支持分组和中间件数据库操作查询构造器为主ORM较弱Eloquent ORM完善模型关系好用权限校验可自定义中间件但默认弱中间件Gate策略结构清晰队列任务内置Queue功能基本够用成熟的事件队列体系重试/延迟很方便定时任务需要自己写crontabScheduler调度器schedule:run统一管理模板引擎内置ThinkTemplate默认Blade也可换成别的中文生态原生中文文档社区中文资料多中文社区逐年丰富但很多问题要查英文如果你现在还在纠结选哪个我建议别光看技术对比先问一句谁负责后期维护如果接手的人只懂ThinkPHP强行上Laravel只会增加沟通成本。技术选型没有绝对的对错只有适合不适合团队现状。2. 从就医流程倒推系统边界挂号系统的功能拆分与角色权限设计2.1 先把线下流程画出来再谈功能做这类系统最容易犯的错是一上来就画表结构。我的习惯是先把线下流程完整走一遍把所有角色和动作列出来再倒推系统边界。以我做的这个卫生服务中心为例患者到院后的完整链路是这样的预检分诊→选择科室→选择医生→选择时段→挂号缴费→候诊签到→医生叫号→就诊→开具检查或处方→离院。这套流程里真正需要线上系统支撑的节点其实是“选择科室→选择时段→挂号缴费→签到候诊”后面就诊环节由医生工作站自己的系统负责我们不做越界的事。这个边界的确定非常重要。很多做挂号系统的人想顺手把电子病历也做了结果半年都交付不了。我当时明确跟需求方讲本系统只覆盖“预约”和“挂号”两个主流程以及支撑这两个主流程所需的排班、医生管理、通知和统计功能。前后端所有需求都围绕这个边界展开其他需求一律记录到“二期”清单里。2.2 角色权限四种身份四种视图系统一共四类角色权限划分必须从一开始就定清楚角色核心权限典型操作患者注册登录、查询科室医生、预约/取消预约、在线支付/退费通过小程序或公众号完成前台收银替患者建档、现场挂号、修改号源、处理退号使用PC端前台界面科室管理员维护本科室医生信息只限本科室数据超级管理员系统全量配置科室、医生、排班模板、统计报表使用管理后台权限模型我用了经典的RBAC角色绑定权限组用户绑定角色。值得一提的细节是Laravel端我用了自带的路由中间件配合can()方法去校验权限在控制器方法里基本上只需要一行代码ThinkPHP端则是自己封装了一个权限中间件框架本身没给现成的需要写些逻辑。这里确实体现了Laravel在这方面的优势。还有一个容易被忽略的权限点数据范围权限。同样是“查看医生列表”患者看到的应该是全部出诊医生科室管理员看到的只能是自己科室的医生超级管理员能看到所有科室。这个数据范围不能用同一个接口解决我最终是分成/api/doctors和/admin/doctors两套接口避免在业务层写一堆if判断角色。2.3 功能清单成型后工作量就清晰了做完流程梳理和角色划分之后功能清单基本就定下来了用户注册登录、科室管理、医生管理、排班模板管理、排班实例生成、预约下单、订单支付/退款、取消预约、签到叫号、停诊通知、爽约统计、后台日/月报表。列出来之后我自己都倒吸一口气单子不小但每个模块的边界都很清晰排期也就有了依据。这里我的经验是功能清单必须写到“动作级”比如“排班模板管理”要拆成新增模板、修改模板、复制上一周模板、批量生成实例这几个动作不然排期一定会失控。3. 数据库怎么设计才能撑住号源、医生排班和预约状态流转3.1 核心表结构六张表打底再逐步扩展数据库设计是整个系统的地基。我最终用的表结构可以浓缩成六张核心表表名关键字段作用usersid, name, id_card, phone, password患者与后台管理员共用一张表type区分角色departmentsid, name, parent_id, sort科室树形结构支持二级科室doctorsid, department_id, name, title, introduction医生档案关联科室schedule_templatesid, doctor_id, week_day, start_time, end_time, capacity, status每周排班模板schedule_slotsid, doctor_id, date, start_time, end_time, capacity, remaining, status某天某个医生某个时段的号源实例appointmentsid, slot_id, user_id, appointment_no, status, paid_at, cancelled_at预约订单记录完整状态流转这里核心的设计思路是“模板与实例分离”。schedule_templates管规律性排班比如某医生每周一三五上午出诊schedule_slots管具体某一天的号源。系统每天凌晨定时任务根据模板批量生成未来14天的号源实例如果遇到临时停诊直接停用某一天的schedule_slots即可不会影响模板。3.2 排班生成与号源数据的关系为什么要把号源拆成独立表而不是在doctors表里存一个剩余号数因为剩余号是随时间变化的且每个时段的号源相互独立。医生周三上午有20个号下午有15个号如果只存一个总量根本没法判断患者约的是上午还是下午。拆成schedule_slots之后每次预约只针对某一个具体时段实例做扣减逻辑就非常直白。生成排班实例的伪逻辑大概是这样找到未来日期范围内所有启用状态的模板排除节假日停诊标记然后批量创建schedule_slots记录remaining初始等于capacity。这个定时任务在Laravel端用Schedule实现在ThinkPHP端则写了一个命令行脚本挂crontab每天早上五点执行一次。生成完后要做一次幂等保护也就是同一天同一个医生同一个时段只能存在一条记录避免重复生成导致号源翻倍。3.3 预约状态机准确地说它就是系统的灵魂预约订单的状态设计非常关键我最开始只设计了“已预约/已取消”两个状态结果上线两天就发现问题患者预约后没付费怎么办到院没签到怎么算医生停诊导致订单要自动变更为取消怎么办后来我把状态扩展成完整的状态机状态值含义允许的下一状态pending待支付预留号源paid, cancelled, expiredpaid已支付/待就诊arrived, cancelled, no_showarrived已签到/候诊中in_progress, completein_progress就诊中completedcompleted已完成终态cancelled已取消终态no_show爽约终态每个状态迁移都会写一条appointment_logs记录包含操作人、动作、时间、备注。这个日志表看着不起眼后期查纠纷、对账、统计爽约率时帮了大忙。而且状态迁移我统一封装在AppointmentService里任何入口小程序、前台、定时任务都走同一个服务方法绝不直接在控制器里改状态字段。3.4 字段类型与索引这些细节别省事字段类型上有个经验appointment_no这种业务单号用varchar(32)并加唯一索引方便按单号查询金额统一用decimal(10,2)绝不用float手机号、身份证号要加索引但不加唯一约束因为确实存在同一个监护人给多个家属挂号的情况。时间字段统一用timestamp别混用datetime不然跨时区或者做日统计的时候会想哭。索引方面appointments表上一定要对slot_id和user_id分别建索引因为高频查询就是“查某个号源被约了多少”和“查某用户的历史预约”。schedule_slots表则对doctor_id date建联合索引排班查询基本都是这个组合。我上线后最严重的一次慢查询就是没给appointments.slot_id加索引导致的200毫秒查询直接飙到2秒加上之后恢复了正常。4. 预约冲突与超卖问题高并发下的号源扣减与防重实现4.1 超卖是怎么发生的一次并发请求的经典事故假设某个时段只剩最后1个号源两个患者同时点击“确认挂号”。如果没有并发控制程序会先查出remaining1A请求判断大于0执行扣减B请求也查出了remaining1同样判断大于0同样执行扣减。最终数据库里也可能出现两条预约记录但号源已被扣成负数——这就是典型的超卖。很多项目会在前端加“按钮点击后置灰”、在接口层加“用户五分钟内不能重复提交”但这两招都防不住并发。前端防御只是降低概率真正的可靠性必须落在数据库层面。我的方案是三层防线数据库事务 行级锁 前端幂等键。4.2 方案对比乐观锁、悲观锁、Redis原子操作方案实现方式优点缺点乐观锁更新时带version条件失败重试并发性能好冲突多时用户体验差悲观锁SELECT ... FOR UPDATE逻辑简单绝对可靠锁等待可能造成连接堆积Redis扣减DECR原子操作性能极高需要处理Redis与MySQL的一致性问题具体场景不同选择也不同。挂号系统的号源扣减频率远低于秒杀单时段一般就几十个号并发压力有限所以我最后选择了悲观锁加事务。这样最保险逻辑也最容易给需求方讲明白。4.3 Laravel实现事务加行锁代码量其实很少public function createAppointment(array $data) { return DB::transaction(function () use ($data) { $slot ScheduleSlot::query() -where(id, $data[slot_id]) -where(remaining, , 0) -lockForUpdate() -first(); if (!$slot) { throw new BusinessException(该时段号源已约满); } $slot-decrement(remaining); return Appointment::create([ appointment_no $this-generateOrderNo(), slot_id $slot-id, // ... 省略其他字段 status pending, ]); }); }重点是lockForUpdate()它会对命中行加排他锁第二个事务在第一个事务提交前会一直等待这样就不会出现两个请求同时读到remaining1的情况。where(remaining, , 0)加了一重数据库层面的兜底哪怕业务代码出bug也不可能把剩余号扣成负数。DB::transaction确保扣减号和创建预约记录要么同时成功要么同时回滚。4.4 ThinkPHP实现同样的思路语法略有区别public function createAppointment($data) { return Db::transaction(function () use ($data) { $slot Db::name(schedule_slot) -where(id, $data[slot_id]) -where(remaining, , 0) -lock(true) -find(); if (!$slot) { throw new BusinessException(该时段号源已约满); } Db::name(schedule_slot) -where(id, $slot[id]) -dec(remaining) -update(); return Db::name(appointment)-insertGetId([ appointment_no $this-generateOrderNo(), slot_id $slot[id], // ... status pending, ]); }); }ThinkPHP 5.1里对应的是lock(true)配合Db::transaction()就可以实现行锁。要注意的是lock(true)必须配合find()使用如果先查出数据再调lock()锁可能没生效。这个坑我实际踩过因为TP的链式查询里lock和查询条件的位置会影响SQL拼接建议写完后打印一下SQL日志确认有FOR UPDATE。4.5 防重不止后端幂等键和取消后的号源释放除了行锁我还给前端加了幂等键机制。用户点击“确认挂号”时前端生成一个client_token后端拿这个token在Redis里做SETNX重复提交同一个token直接返回“请勿重复操作”。这个token同时也能挡住部分脚本刷接口的行为。取消预约后的号源释放也是一个容易出错的地方。我规定只有pending和paid状态的订单可以取消取消时状态置为cancelled同时把对应schedule_slots的remaining加回来并且给用户退款如果已支付。这两个动作同样放在一个事务里避免出现订单已取消但号源没恢复的脏数据。实测中我用压测工具模拟了200个并发请求同时抢同一个只剩10个号的时段最终预约成功的记录恰好是10条没有一条重复没有负号源数据库一致性没问题。这个结果验证了“事务行锁”方案在当前量级下完全够用没必要为了炫技引入复杂的Redis扣减方案。5. 消息通知、支付对接与行政后台容易被低估的配套模块5.1 预约成功和停诊通知设计一个可插拔的通知通道挂号系统逃不掉消息通知最基础的两个场景是“预约成功提醒”和“医生临时停诊提醒”。通知渠道至少包括短信、公众号模板消息或小程序订阅消息。一开始我把通知逻辑直接写在预约Service里后来发现每次加一个渠道就要改业务代码非常痛苦。重构后我抽象了一个通知接口interface NotificationChannel { public function send(string $to, string $title, string $content): bool; }短信渠道、微信渠道、站内信渠道分别实现这个接口业务端只调Notification::send()。Laravel自带成熟的Notification组件可以直接扩展ThinkPHP版本我是在app/Service/Notification目录下手动实现的同样逻辑。这个抽象做完之后新增一个“APP推送”只需要加一个实现类业务代码一行不用动。5.2 挂号费支付与退款回调处理是重中之重支付模块不是自己做支付而是对接第三方统一支付接口。流程是用户提交预约且状态为pending后端生成支付单号并返回支付参数用户完成支付后第三方回调通知后端后端在回调里校验订单信息把订单状态从pending改为paid同时更新号源状态。这里最容易出问题的是回调处理必须做到“一次且仅一次”的语义校验。我会判断回调单号是否存在、订单状态是否已经为paid如果已经是paid就直接返回成功不再重复改状态。退款则走反向流程用户取消订单若已支付则调用退款接口退款回调成功后把状态标记为refunded。千万别在取消订单的路上直接改状态而不管退款结果否则会出现“订单显示已取消但钱没退”的客诉。5.3 爽约规则与黑名单设计越简单越好用爽约的定义是患者预约成功且已签到状态为paid但在就诊时段结束后仍未到院签到。为了避免运营规则太复杂我用的是最简单的策略就诊日次日零点跑定时任务扫描paid状态且就诊时间已过的订单标记为no_show一个月内爽约两次进入黑名单限制未来一周不能在线预约。只有线上下单才参与爽约判定前台人工挂号的订单不参与。这个规则在需求确认时和一线的护士长反复对齐过因为“哪种算爽约”的界定他们最清楚。我也建议后来者在这一步多花时间跟运营同事确认技术本身不复杂但规则理解偏差会导致上线后各种客诉。5.4 后台报表管理者真正关心的几个数字行政后台除了基础CRUD最不能缺的是统计报表。我做了三张核心报表科室号源使用率报表某科室某天放号多少、已约多少、使用率百分比、医生出诊工作量报表某医生周期内接诊人数、平均每人时长、患者爽约率报表。这些报表的查询条件都很简单真正麻烦的是数据口径比如“已挂号数”要不要剔除取消订单“使用率”分母是放号数还是可预约天数。我的建议是开发时先把口径写在代码注释里不然三个月后你自己都忘了当初怎么算的。技术实现上这类统计报表不建议实时跑大聚合SQL我是每天晚上用定时任务把当天的统计结果预聚合到一张daily_stats表里后台直接查表响应时间基本都在100毫秒以内。6. 从本机到服务器部署、日志与性能调优的实操记录6.1 部署环境与基础架构最终上线环境用的是Nginx PHP-FPM MySQL 5.7 Redis 6.0服务器配置不高2核4G但支撑卫生服务中心一天几百号的预约完全没有压力。Nginx里最关键的是伪静态配置Laravel和ThinkPHP的入口都在public目录需要把请求都转发到index.php。Laravel下面这段配置是最常用的location / { try_files $uri $uri/ /index.php?$query_string; }ThinkPHP的伪静态略有不同但思路一致。另外一定要确认PHP-FPM的upload_max_filesize、memory_limit这些参数别等上传证件照片报错的时候才想起来调。6.2 Laravel部署最容易翻车的三个细节第一storage目录权限。storage和bootstrap/cache必须让PHP-FPM进程有写权限我吃过没配权限导致日志写不了、页面白屏的亏。第二php artisan config:cache之后如果改了.env文件没重新缓存配置会不生效而如果改完.env不清理缓存反而可能让老配置继续续命这个细节很容易迷惑人。第三队列监听。通知和回调里用到的队列任务必须保证php artisan queue:work常驻运行否则消息通知会积压。我用的是supervisor托管队列进程比直接用nohup挂后台靠谱得多。6.3 ThinkPHP部署runtime权限与日志切割ThinkPHP端部署相对简单但runtime目录权限是同样的坑一定要确保可写不然各种缓存、日志都会出问题。另外ThinkPHP的日志是单文件追加时间久了文件会非常大最好在运维层面做一下按天切割或者定期清理不然磁盘很容易被撑满。我在上线前就把日志级别调整成了record只记录error级别避免generate级别刷出海量调试日志。6.4 性能调优慢查询日志与Redis缓存热点数据上线稳定后我做了一轮性能排查。打开MySQL慢查询日志发现大部分耗时SQL集中两类一类是后台报表查询通过预聚合表解决了另一类是首页科室列表和医生列表本身查询不慢但每次请求都查数据库白白浪费时间。解决方案是加Redis缓存科室列表缓存到Rediskey为departments:all排班变更或医生信息修改后主动删除缓存。医生排班列表则按“科室日期”组合成key比如schedule:department:5:2025-01-10缓存有效期设为五分钟或排班变更时失效。这个优化做完接口平均响应时间从180毫秒降到了30毫秒左右效果非常明显。6.5 安全加固这些坑基本每个医疗系统都会遇到最后说安全围绕的是几个真实发生过的攻击场景。接口层面所有需要登录的接口都校验了用户身份避免水平越权——患者A不能通过改URL里的ID去查看患者B的预约记录。提交预约时校验了CSRF Token尤其是后台管理界面。前端登录加入了图形验证码防止脚本批量注册。支付回调接口做了签名验证并且对回调IP做了白名单校验避免伪造回调。还有一点容易被忽视敏感信息脱敏。身份证号、手机号在列表接口中默认不返回只有本人查看详情或后台管理员操作时才展示完整信息。这些虽然是常识但在这个行业里安全问题从来不是技术多高深的问题而是有没有意识去做的问题。整套系统从开始调研到上线前后花了大概两个半月。回头看最值得分享的经验不是某个具体函数怎么写而是一个认知预约系统的灵魂是状态机和并发控制而不是页面漂不漂亮。把状态流转、号源扣减这些底层逻辑想透了不管用ThinkPHP还是Laravel写出来的代码都不会差到哪里去。希望这篇记录能帮你少踩几个坑。最后再提一句如果真正要上线医疗业务系统合规要求会比普通系统严格得多这些环节建议在做需求调研阶段就主动向相关方确认清楚。