简介基于ThinkPHP框架与MySQL数据库的互联网医院源码面向需要搭建在线问诊平台的开发者、医疗信息化从业者及中小型医疗机构。资源构建了完整的在线问诊闭环包括患者注册、预约挂号、在线交流、病历归档、费用支付等核心流程有助快速打造可运行的服务系统。压缩包共两千四百四十二个文件大小三十五点五一MB以PHP业务逻辑、PHPT模板、HTML页面为主同时提供了丰富的GIF演示图、JS交互脚本、CSS样式表以及接口文档、SQL部署数据、Apache安全配置和微信验证文件便于部署与二次开发已有1083人学习下载。代码层次清晰用户可借助接口文档快速掌握API调用方式从入口文件开始可梳理系统初始化链路通过HTACCESS规则加固敏感接口配合测试数据能迅速生成可演示环境。这套源码既能用于毕业设计或课程练习也可作为商业互联网医院平台的基础框架适合不同阶段的开发者。1. 从挂号窗口到在线问诊互联网医院系统的技术底座医疗资源的分发效率长期卡在「物理空间」这道坎上三甲医院候诊区坐满人基层诊室门可罗雀复诊患者为一次开药请假半天。互联网医院要解决的就是把问诊流程里所有不依赖物理接触的环节——挂号、图文咨询、复诊开方、报告回传——搬上线让医生的碎片化时间和患者的等待时间同时被压缩。这套基于 ThinkPHP 和 MySQL 构建的源码正是完成这件事的可直接部署的工程底座。它适合两类人一类是接手医疗信息化项目的 PHP 工程师需要一套符合国标问诊流程的参考实现另一类是准备自建在线问诊平台的创业团队想用最小成本验证业务模型。你拿到的不只是几个 PHP 文件而是一套完整的 MVC 分层、数据表设计、API 鉴权和第三方支付对接的现场样本。2. ThinkPHP 入口与问诊业务分层从 index.php 到控制器编排2.1 index.php 作为唯一入口的调度机制这套源码的请求链路从根目录的 index.php 开始所有前端请求无论来自微信内置浏览器、iOS 还是 Android WebView最终都汇聚到这个文件完成初始化。index.php 并不直接处理业务它负责三件事定义应用根路径常量、加载 ThinkPHP 框架的启动引导文件、捕获全局异常和错误。// index.php 核心启动逻辑 define(APP_PATH, __DIR__ . /application/); define(BIND_MODULE, index); // 绑定默认模块 require __DIR__ . /thinkphp/start.php;代码说明APP_PATH指向 application 目录框架会自动识别模块结构BIND_MODULE将入口强制绑定到 index 模块意味着所有访问默认走前台模块后台管理模块admin需要通过独立的入口文件或 URL 路由规则访问。这是医疗系统常见的双入口隔离策略避免后台管理接口直接暴露给公网。如果部署时发现访问后台路径 404第一排查点就是BIND_MODULE的配置是否限制了模块进入。入口调用 start.php 后ThinkPHP 会执行路由解析、中间件加载、依赖注入容器初始化等一系列动作。对开发者而言真正需要关心的是 application 目录下的 controller 和 model 两个子目录前者写业务流转后者写数据映射。这套体系中问诊业务的控制器承担了比普通 CRUD 更重的编排职责一个完整的问诊提交动作要串联患者身份校验、医生在线状态检查、问诊记录落库、IM 消息推送四个环节顺序错一步就会产生脏数据。2.2 问诊会话控制器的状态机实现在线问诊不是一次性请求而是多轮交互的状态流转。源码中问诊控制器使用了一个状态整型字段来标记会话所处阶段这是医疗业务里非常实用的设计避免了用一堆布尔值拼凑状态的做法。public function createSession($patientId, $doctorId, $type) { // 状态机1待支付 2待接诊 3问诊中 4已完成 5已关闭 6待退款 $session [ patient_id $patientId, doctor_id $doctorId, type $type, // 1图文 2电话 3视频 status 1, // 初始状态为待支付 create_time time(), update_time time(), sn $this-generateSn($patientId) // 订单号生成 ]; return Db::name(consult_session)-insertGetId($session); }代码说明generateSn是内部方法通常拼接日期、随机数和患者 ID 后做哈希取前位确保并发下订单号不冲突。状态字段使用 int 而不是 varchar目的是配合索引加速按状态筛选的统计查询——运营后台经常要统计「今日待接诊会话数」整型字段走索引的效率高出一个数量级。类型字段type决定了后续调用的交互通道图文问诊走普通消息队列视频问诊需要额外调用实时音视频服务的房间创建接口这是控制器里需要做分支判断的地方。状态流转不是靠控制器里随意赋值完成的源码里抽出独立的ConsultStatusService把所有允许的状态迁移路径集中管理。这个服务的价值在医疗场景中很明显患者支付后系统自动将状态推进到待接诊医生接诊后推进到问诊中但禁止从已完成回退到问诊中。如果这套逻辑散落在多个控制器里出现越权操作的风险会显著上升。2.3 患者就诊记录的数据落库边界问诊过程中的每一句话、每一张处方、每一份检查报告都需要有对应的物理存储位置。这套源码的 MySQL 库表中核心表现在三个patient 表存基础档案consult_session 表存会话业务数据consult_message 表存问诊消息内容。第三张表在开发时容易被当成日志表处理但对医疗系统来说问诊消息涉及医疗纠纷追溯和监管审计写入策略和普通日志完全不同。CREATE TABLE consult_message ( id int(11) NOT NULL AUTO_INCREMENT, session_id int(11) NOT NULL COMMENT 会话ID, sender_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 发送者类型 1患者 2医生 3系统, content_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 内容类型 1文本 2图片 3语音 4处方, content text COMMENT 消息内容加密存储, create_time int(11) NOT NULL, PRIMARY KEY (id), KEY idx_session_createtime (session_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;核心索引idx_session_createtime是组合索引查询某个会话的全部消息时这样的设计避免了全表扫描响应时间能控制在百毫秒以内。患者端打开问诊聊天窗口时只需一条 SQL 就能拉取完整上下文如果索引设计成单一 session_id 字段随着消息量增长会逐渐出现慢查询用户感知就是聊天记录越加载越卡。内容字段使用了text类型而非longtext是因为单条医疗消息的长度通常在几百字以内text 类型足够承载并且避免了大字段对缓冲池的占用。案例中内容加密逻辑对应源码里的 XXTEA 算法密文写入 content 字段查询时才做解密。3. XXTEA 加解密在问诊数据传输链路中的落地3.1 为什么会在 PHP 医疗源码里出现 C 扩展文件解压源码后你会看到 php_xxtea.c 和 xxtea.c 两个文件外加对应的 CREDITS 和 COPYING 文件。这是 XXTEA 分组密码算法的 C 语言实现被编译为 PHP 扩展后在问诊请求参数加密、接口返回报文脱敏、处方数据落库加密三个场景中使用。PHP 生态里常见的加解密首选是 openssl 扩展提供的 AES为什么这套源码选择 XXTEA 作为补充——原因在于部分部署环境是低配云主机openssl 扩展在 PHP 5.x 时代可能未启用而 XXTEA 的 C 实现不依赖外部库编译后直接可用对老旧的医疗行业服务器运维环境更友好。另一个考量是数据长度。问诊请求中的图片 URL、语音消息路径、处方缩略图地址这些字段长度不固定而 XXTEA 支持动态长度分组加密实现上比固定分组的 AES 更灵活。这套源码把 XXTEA 用于短字段的加密传输而不是做全报文 HTTPS 替代定位是应用层的二次保护。3.2 密钥派生与 PHP 侧解密调用示例直接调用加解密函数时密钥通常不写死在 PHP 代码里而是从配置文件读取后做一次哈希运算派生出算法密钥。下面展示的是消息内容解密的标准用法function decryptContent($cipherText, $appKey) { $key md5($appKey . consult_message, true); // True 返回原始二进制 $plainText xxtea_decrypt(base64_decode($cipherText), $key); if ($plainText false) { Log::record(XXTEA 解密失败密文前缀: . substr($cipherText, 0, 20), error); return ; } return $plainText; }xxtea_decrypt是编译扩展提供的函数第一个参数要求二进制密文所以外层的base64_decode必不可少——网络传输中密文经常以字符串形式拼接在 JSON 结构里不还原二进制直接解密会得到乱码。密钥派生使用 md5 加盐哈希对同一个字段使用固定盐值保证可逆性如果使用随机盐会导致同一密文每次解密结果不同那设计就有问题了。解密失败时先截取密文前缀记录日志不用急着打印全文避免敏感内容写入日志文件造成二次泄露。3.3 加密边界与传输链路的配合百分之九十的实现问题不在加密代码本身而在边界划分。这套源码中XXTEA 加密的范围是问诊消息正文、处方备注字段、患者主诉文本不包括患者的姓名和手机号这类主索引字段。原因是主索引字段经常作为检索条件出现在 SQL 的 WHERE 子句中如果加密存储每次查询都需要全表解密后才能比对性能完全不可控。患者姓名和联系方式依赖数据库本身的访问控制和 HTTPS 传输保护消息内容因为可能包含敏感的病情描述需要数据库泄露场景下的最后一道防线。C 扩展的编译安装了可能会遇到的第一个坑服务器未安装 phpize 工具。Debian/Ubuntu 系统需要执行apt-get install php-dev安装 PHP 开发扩展的基础包然后才能进入源码目录执行phpize ./configure make make install。编译产物 .so 文件的加载路径需要写入 php.ini 的 extension 配置中如果不清楚模块目录位置用php -i | grep extension_dir查询。测试环境验证扩展是否加载成功用命令行执行php -m | grep xxtea。4. 问诊 API 接口契约设计从接口文档到微信服务号闭环4.1 接口文档.docx 的内容组织与状态码约定资源包中的 接口文档.docx 是一份完整的 API 契约说明包含账号体系、问诊流程、支付链路、电子病历四个模块。文档里所有接口统一遵循 REST 风格请求返回 JSON 结构外层包含 code、message、data 三个固定字段。这里值得说明的是成功码和业务码分离的设计HTTP 状态码始终返回 200真实业务结果放在响应 body 的 code 字段中。这种设计在医疗项目里更实用因为某些老旧的医院前置网关会拦截非 200 的响应统一返回 200 能避免网关层吞掉错误信息。问诊相关接口的状态码定义遵循一套约定以 1001 开头表示参数错误以 2001 开头表示账户权限问题以 3001 开头表示问诊业务状态冲突以 4001 开头表示支付环节异常。你可以查看 api/controller/Consult.php 文件文件头部有一个完整码表常量定义。对接第三方体检机构或医院 HIS 系统时这个码表就是双方约定的语义字典对方的开发人员拿到文档不需要看内部实现也能完成联调。4.2 .htaccess 的 URL 重写与接口防刷配置Apache 环境下入口文件路径直接暴露时URL 结构会变成index.php?s/index/consult/detailid123这样的形态不美观也不安全。源码根目录的 .htaccess 文件解决了这个问题搭配 ThinkPHP 的路由伪静态规则将真实入口隐藏起来。IfModule mod_rewrite.c Options FollowSymlinks -Multiviews RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?s/$1 [QSA,PT,L] # 接口防刷同一IP每分钟最多120次请求 FilesMatch api\.php Require not ip 10.0.0.0/8 /FilesMatch /IfModule第一段 RewriteRule 将不存在的文件或目录请求全部交给 index.php 处理配合 ThinkPHP 的 pathinfo 模式URL 可以表现为/consult/detail/id/123的形式。QSA 标记表示保留原有查询参数PT 表示将重写后的路径传递给后续处理阶段。如果站点部署在 Nginx 上这个规则需要对应改成try_files $uri $uri/ /index.php?s$uri$args;的写法Apache 的规则在这里不生效这一点经常成为从 Apache 迁移到 Nginx 时的坑。接口防刷方面脚本不是只靠 .htaccess 的 IP 限制更核心的是需要在控制器公共方法里校验请求频率。实际做法是拿用户 Token 作为维度每 5 分钟限制一定次数超过后响应 429 状态码并附带 Retry-After 响应头客户端根据这个响应头做退避重试。4.3 MP_verify 验证文件与微信生态对接源码包里的MP_verify_KvPusKvI7pCo0joP.txt是微信公众平台域名校验文件用于验证开发者对服务器的控制权。文件内容就是微信后台生成的一串随机字符公众平台要求你将它放到域名根目录下文件名和内容必须是微信提供的完全一致的状态。这个校验的作用是确认你的服务器域名与公众号后台填写的信息一致验证通过后才能在微信浏览器中唤起支付、获取用户 openid。问诊流程中患者从公众号菜单进入在线问诊页面网页授权后服务端拿到用户 openid 关联到平台内部患者账号这一层映射完成后支付回调里的订单号才能准确关联到对应的问诊会话。实际对接微信支付接口时还需要处理证书文件 apiclient_cert.pem 的存放路径这套源码建议将其放在 application/extra/ 目录下并设置目录权限为 600。支付回调地址在微信商户平台配置为https://你的域名/index.php?s/pay/notify注意回调地址必须是公网可以访问的 HTTPS 地址且不能带任何查询参数微信在 POST 回调时会直接访问这个完整 URL。回调验签逻辑要放在控制器最前面先校验返回码和签名再更新订单状态顺序反了可能造成状态被伪造的请求篡改。5. 前端组件组织与移动端问诊页面的渲染路径5.1 jquery-weui 和 layui 共存的原因源码资源同时包含 jquery-weui.min.css、weui.min.css、layui.css 三套样式文件这其实是管理端与移动端的双前端架构。layui 服务的是医生后台和平台运营管理界面数据表格、表单校验、弹出层组件非常全能医生排班管理页面、问诊统计报表页面都在这个体系下工作。而 jquery-weui 是微信生态下的移动端组件库按钮、列表、对话框、动作表的视觉风格与微信内置浏览器高度一致患者进入服务号问诊页面时界面切换几乎没有违和感。移动端页面在病患问诊场景里还有一个小细节就是页面里引用 swiper.css 实现病情图片的横向滑动浏览。患者上传的检查报告单往往是长图或者多图使用 swiper 的轮播模式可以让医生在问诊窗口内快速滑动查看不用点击小图等待大图加载。单图直接渲染img标签多图则套用swiper-container容器结构这个判断在模板文件里用条件语句实现。5.2 移动端问诊会话页面的消息轮询策略Web 版本的即时聊天不能依赖长连接尤其医院内网带宽不稳定WebSocket 连接经常断开重连反而造成消息乱序。这套源码的移动端问诊页面采用固定间隔轮询 本地缓存游标的方式拉取新消息轮询间隔默认 3 秒。每次轮询带上会话 ID 和最后一次消息的 ID 值服务端只返回比这个游标更大的新消息避免重复拉取历史数据。function pollNewMessages(sessionId, lastMsgId) { $.ajax({ url: /index.php?s/consult/pollMessages, type: POST, data: { session_id: sessionId, last_msg_id: lastMsgId }, dataType: json, success: function(res) { if (res.code 0 res.data.length 0) { res.data.forEach(renderMessageItem); var newLastId res.data[res.data.length - 1].id; localStorage.setItem(chat_ sessionId, newLastId); lastMsgId newLastId; scrollToBottom(); } setTimeout(function() { pollNewMessages(sessionId, lastMsgId); }, 3000); }, error: function() { setTimeout(function() { pollNewMessages(sessionId, lastMsgId); }, 5000); // 失败时拉长间隔避免频繁请求 } }); }轮询接口的响应数据里包含消息 ID、发送者类型、内容类型和渲染需要的富文本模板renderMessageItem根据内容类型分别渲染文本气泡、图片卡片或处方卡片。lastMsgId 保存到 localStorage 是为了退回到列表页再进入时直接定位到未读位置。成功回调和错误回调的定时策略不同有意的区分——错误时从 3 秒延长到 5 秒防止服务端暂时故障时客户端继续高频轰炸接口。接口层对同一 sessionId 的轮询间隔做了服务端校验间隔小于 2 秒会直接拒绝请求既保护数据库查询压力也逼着客户端遵守轮询节奏。5.3 静态资源版本号与浏览器缓存控制微信内置浏览器的缓存策略相当激进一套 JS 或 CSS 文件更新后患者端经常仍加载旧版本导致界面错乱甚至接口数据渲染失败。这套源码的模板入口文件在引入静态资源时全部带上了版本号参数比如layui.js?v2.4.5这样的形式。版本号在发布时手工更新或通过脚本替换推荐的做法是在公共配置文件中定义一个静态资源版本常量模板里统一引用这个常量// application/config.php static_version 20240116, // 模板文件中引用 link relstylesheet href/static/css/weui.min.css?v{$static_version}浏览器视角下?v20240116和?v20240117是两个不同的 URL缓存指纹不匹配就会强制重新拉取资源。需要注意版本号更新频率不要过于频繁一天一次是合理的节奏如果每次 git 提交都更新版本号会让患者端每次都重新下载全部静态资源流量开销增大。合理策略是只在静态文件有实质改动时才递增版本同一版本内多次发布不影响前端缓存。6. 部署期排错技巧定位 XXTEA 扩展加载失败与 MySQL 连接瓶颈部署这套源码时最容易遇到的三个故障一是 PHP 扩展加载后进程报错二是高并发下单表数据量增长引发的查询超时三是 URL 重写规则不生效导致的页面 404。针对第一个问题登录服务器后先用php -v确认 PHP CLI 环境能否正常输出版本信息再执行php -m查看加载模块列表。如果列表中没有 xxtea打开 php.ini 确认 extension 配置行没有被注释同时检查扩展 .so 文件是否存在且权限为可读。更隐蔽的问题是 PHP 的线程安全版本与非线程安全版本扩展不兼容Windows 环境使用php -i | findstr Thread Safety查看当前的线程安全模式选择对应的 php_xxtea.dll 版本否则扩展加载后会导致 PHP 进程直接崩溃。MySQL 连接瓶颈的表现是页面能打开但数据加载极慢查看慢查询日志发现大量针对问诊消息表的全表扫描。前面提到idx_session_createtime组合索引是标准解法还有一种情况是天气预报式的缓存方案没做好同一患者反复刷新问诊列表页面时每次请求都执行相同的数据库查询。改进方案是接入 Redis 缓存缓存键设计成consult_session_{patientId}_{page}查询结果序列化后缓存 30 秒。配置文件中数据库连接参数预留了redis配置段部署时装好 Redis 扩展并去除配置注释就能生效。微信端进入页面出现 404 时排查顺序是先确认 .htaccess 文件是否随项目完整上传很多 FTP 工具会隐藏点开头的文件导致遗漏再检查 Apache 的 mod_rewrite 模块是否启用a2enmod rewrite启用后重启 Apache最后看 application/config.php 中url_route_on是否是 true 状态路由关闭状态下 pathinfo 方式无法解析。nginx 环境则检查配置文件中try_files指令是否正确携带了$args参数漏掉时 GET 请求的查询参数会全部丢失表现为列表页能打开但翻页和筛选完全失灵。部署验证的最终步骤是走一遍完整业务链路新建患者账号、搜索并选择医生、发起图文问诊并支付、医生端接诊并回复消息、患者端确认收到消息。五个环节全部打通再打开 MySQL 的 general log 确认每个步骤的 SQL 语句都正确落在对应的表上这套互联网医院系统就算正式运行起来了。本文还有配套的精品资源点击获取