基于微信小程序的在线问诊与电子处方流转平台设计

两个月前，我帮一个计算机专业的学弟看毕业设计选题。他已经换了三个题目，第一个太简单被导师否了，第二个找不到完整源码，第三个做到一半发现技术栈太老。最后我给他的建议是：做一个微信小程序版的在线问诊与电子处方流转平台。

这个选题能在计算机毕业设计里常年保持热度，不是没有原因的。它天生就适合做毕业设计：前端有微信小程序这种自带真实用户场景的载体，后端能覆盖用户体系、医生排班、问诊会话、处方管理、订单支付、权限控制这些高频业务模块。论文好写，工作量好展示，答辩时也有清晰的功能演示流程。更重要的是，这类项目对于后续找工作也有参考价值，一个完整的小程序前后端项目放进简历，比十个零散 Demo 都有说服力。

本文要聊的核心就是：基于微信小程序实现在线问诊与电子处方流转平台，并附上可直接借鉴的开源项目结构。我会先讲清楚电子处方流转到底是什么、和普通电商订单有什么区别，然后从技术选型、数据库设计、核心业务流程、后端接口实现到小程序端代码，一步步拆解。同时会给出几个常见的坑和工程建议，帮你在毕设阶段少走弯路。

如果你正在做这个方向的选题，或者被导师要求做一个小程序 + 电子处方流转的项目，这篇文章适合你从头读到底。如果你只是想找开源项目跑通流程，从第 3 节和第 5 节开始看，可以直接跳到代码部分。

1. 在线问诊与电子处方流转，到底在做什么

先拆解一下这个项目标题里的两个核心概念。

在线问诊是一个大家都很容易理解的功能。患者在微信小程序里选择医生、提交病情描述、与医生进行图文或语音问诊，医生查看后给出诊断建议。它本质上是一个医患之间的异步/同步沟通工具，但又比普通聊天多了一层“诊断”的业务含义。

电子处方流转是容易被忽视、但真正决定项目含金量的部分。它不是简单的“医生开个药单”，而是一个完整的业务闭环：

1. 医生在问诊会话中确认患者的病情后，在系统里开具电子处方，包括药品清单、用法用量、用药天数。
2. 处方经过合理性校验，比如药品库存是否充足、剂量是否超限、是否存在重复用药。
3. 处方被流转到药房系统，药房审核通过后进行配药、发货或到店自提。
4. 患者在小程序端能实时看到处方的状态：待审核、审核通过、已配药、已完成。

这个流程意味着，你的系统里至少有三个角色在同一个业务链路上协作：患者、医生、药师。如果再加上管理员，这就是一个典型的多角色 + 状态机 + 业务流程流转系统。

从毕业设计的评分角度看，多角色本身就比单角色的管理系统难一个层级。导师看到的不只是 CRUD，而是学生有没有理解真实业务中“谁操作、什么状态下能操作、操作后进入什么状态”这套逻辑。

下图描述了系统核心业务状态流转关系（文字版，便于在论文里使用）：

患者提交问诊单 → 医生接诊 → 问诊对话 → 医生开具处方 → 处方待药师审核 → 药师审核通过 → 药房配药 → 患者确认收货/到店自提 → 订单完成

2. 技术选型：为什么小程序端 + Spring Boot 是主流组合

技术选型是毕业设计开题阶段最先要确定的事情。同一个项目用不同技术栈，代码量、难度、就业价值完全不同。

从我看到的开源项目和近几年热门毕设选题来看，这个方向的系统通常采用下面的组合：

为什么 Spring Boot + MyBatis-Plus 是小程序后端项目最稳妥的选择？我的判断是三个原因：

第一，资料量大。毕业设计最常见的坑是在一个冷门技术栈上卡住后找不到解决方案。Spring Boot + MyBatis-Plus 是中文互联网覆盖最全的 Java 后端组合，你遇到的 90% 的报错都能搜到答案。

第二，代码结构清晰。Controller、Service、Mapper 三层结构天然适合论文中的系统设计章节。画分层架构图、写类设计、做数据库 ER 图都方便。

第三，岗位匹配度高。如果后续求职方向是 Java 后端开发，这个技术栈就是面试高频范围。

微信小程序端这里有一个决策点：用原生小程序还是 uni-app？

如果你是打算快速跑通项目，建议直接使用微信小程序原生。因为大部分开源毕设项目的代码都是原生写的，你在学习和改造时可以直接对照。

如果你已经会 Vue，且希望以后能把代码打包成 H5 或 App，则可以选择 uni-app。但要注意，uni-app 从项目的整体复杂度上会引入更多概念，毕设答辩时反而要花时间解释“为什么多这一层”。

有一点必须提醒：不要用云开发代替自建后端。某些实时数据库方案虽然开发速度快，但论文中很难展开写“服务器端核心代码实现”，因为后端逻辑都被云函数替代了。计算机毕业设计最看重的是后端逻辑设计和数据库建模，自建 Spring Boot 后端才是稳妥路线。

3. 数据库设计：一张处方表撑起整个业务闭环

在写一行代码之前，先把数据库表设计理清楚。我见过太多毕设项目在中期改表结构改到崩溃，原因就是前期没有把核心业务表的关系想明白。

一个在线问诊与电子处方流转平台，最少需要以下核心表：

下面这张表的关系值得多说几句。

处方主表（t_prescription）是整个系统的枢纽。它同时关联了患者、医生和问诊记录。处方明细表（t_prescription_item）则记录每张处方里的多个药品，因为一张处方可以包含多种药，明细表和处方表是多对一关系。药品库存信息挂在 t_drug 上，而订单表通过 prescription_id 反向关联处方，这样“问诊 → 开方 → 购药”才能串成一条完整链路。

在建表时，有几个字段需要特别设计好：

状态字段建议使用int存储，而不是字符串。处方状态可以用 0 表示待审核，1 表示审核通过，2 表示已配药，3 表示已完成，-1 表示已驳回。用数字存储的好处是查询和比较都方便，而且逻辑上更清晰。在代码中定义一个状态枚举类统一管理，避免魔法数字散落各处。

金额字段使用decimal(10,2)。药品价格和订单金额都不能用 float 或 double，否则容易出现精度问题。这个问题在答辩时可能会被老师点名提问，会正确解释“为什么不用浮点数”是加分项。

逻辑删除统一使用deleted字段（0 正常，1 已删除），而不是物理删除。MyBatis-Plus 内置了逻辑删除支持，一个注解就能搞定，这也是工作量展示的一部分。

4. 核心业务模块拆解：问诊、处方、订单如何串联

在线问诊系统从功能清单上看，可能列出二三十个小功能，但真正决定业务流程的只有三个闭环。

4.1 问诊闭环

患者在首页选择科室，进入医生列表，选择可问诊的医生后提交问诊订单。问诊订单可以有两种交互形式：一种是即时对话模式，一种是留言问诊模式。

对于毕设系统，我推荐采用“留言式问诊 + 医生回复”的简化模式，理由是技术复杂度可控，核心痛点依然完整。患者提交病情描述后，医生在待接诊列表里看到，选择接诊后进入问诊室进行多轮对话。

这里要强调的是，不要为了追求“实时聊天”而引入 WebSocket。虽然 WebSocket 是技术亮点，但它会给项目带来额外的复杂度，比如连接管理、消息推送、离线消息处理。对于一般毕设，可以采用轮询方式：小程序端每隔几秒请求一次“获取新消息”的接口。虽然不够“实时”，但在演示场景下完全够用，而且可以在论文中写“采用定时轮询方案，避免长连接的资源开销”，这也是一个合理的技术决策解释。

4.2 处方闭环

问诊结束后，医生在问诊详情页录入处方。录入内容包括药品选择、剂量、频次、天数等。医生提交后，处方状态为待审核。

药师端可以查看所有待审核处方，核对药品信息是否合理，然后选择通过或驳回。审核通过后，处方状态变为可购买状态，患者端出现“去购药”按钮。

处方审核这个环节非常值得实现，因为它是“流转”二字的体现。如果系统只做到医生开方、患者查看，那这个项目本质还是一个问诊系统，谈不上“处方流转”。多一个药师审核环节，业务流程完整度立刻提升一个档次。

4.3 订单闭环

患者点击“去购药”，系统根据处方明细自动生成订单，展示药品清单、总价、收货地址。患者提交订单并模拟支付成功（毕设项目可以不接真实支付，用模拟支付代替），订单状态变为已支付。

药师端和后台管理端可以看到新订单，确认配药发货。患者端订单状态变为配送中，最后点击确认收货，整个流程闭环。

如果追求完整，还可以增加一个“退药退款”的流程，但这属于加分项，不作为核心功能要求。

5. 后端代码实现：从 controller 到 mapper 的完整链路

下面结合代码演示处方创建与查询的核心逻辑。先明确环境：

• Java 8 或 11
• Spring Boot 2.x（版本以实际项目为准）
• MyBatis-Plus
• MySQL 5.7 或 8.0
• Maven 3.x

5.1 数据库建表脚本

-- 处方表 CREATE TABLE `t_prescription` ( `id` bigint NOT NULL AUTO_INCREMENT, `prescription_no` varchar(32) NOT NULL COMMENT '处方编号', `consultation_id` bigint NOT NULL COMMENT '问诊ID', `doctor_id` bigint NOT NULL COMMENT '医生用户ID', `patient_id` bigint NOT NULL COMMENT '患者用户ID', `status` tinyint NOT NULL DEFAULT '0' COMMENT '状态:0待审核 1审核通过 2已配药 3已完成 -1已驳回', `diagnosis` varchar(500) DEFAULT NULL COMMENT '诊断结论', `audit_remark` varchar(255) DEFAULT NULL COMMENT '审核备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `deleted` tinyint NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 处方明细表 CREATE TABLE `t_prescription_item` ( `id` bigint NOT NULL AUTO_INCREMENT, `prescription_id` bigint NOT NULL COMMENT '处方ID', `drug_id` bigint NOT NULL COMMENT '药品ID', `drug_name` varchar(100) NOT NULL COMMENT '药品名称', `spec` varchar(100) DEFAULT NULL COMMENT '规格', `price` decimal(10,2) NOT NULL COMMENT '单价', `dosage` varchar(50) NOT NULL COMMENT '每次用量', `frequency` varchar(50) NOT NULL COMMENT '频次', `days` int NOT NULL COMMENT '天数', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

一个容易被忽略的细节：处方明细表中冗余存储了drug_name、spec、price。为什么不直接关联药品表？因为历史数据不可变。如果医生开的处方在患者购买前药品价格发生了调整，那处方上的价格必须保持开方时的原价。这就是冗余字段的业务意义，在论文数据表设计部分可以写出这样的设计理由。

5.2 端点层：处方 Controller

// 文件路径：src/main/java/com/example/medical/controller/PrescriptionController.java @RestController @RequestMapping("/api/prescription") public class PrescriptionController { @Resource private PrescriptionService prescriptionService; /** * 医生提交处方 */ @PostMapping("/create") public Result createPrescription(@RequestBody PrescriptionCreateDTO dto) { Long prescriptionId = prescriptionService.createPrescription(dto); return Result.success(prescriptionId); } /** * 药师审核处方 */ @PostMapping("/audit") public Result auditPrescription(@RequestBody PrescriptionAuditDTO dto) { prescriptionService.auditPrescription(dto); return Result.success(null); } /** * 患者查询自己的处方列表 */ @GetMapping("/list/{patientId}") public Result listByPatient(@PathVariable Long patientId, @RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize) { Page<PrescriptionVO> page = prescriptionService.pageByPatient(patientId, pageNum, pageSize); return Result.success(page); } }

5.3 服务层：处方状态流转的核心

// 文件路径：src/main/java/com/example/medical/service/impl/PrescriptionServiceImpl.java @Service @Slf4j public class PrescriptionServiceImpl implements PrescriptionService { @Resource private PrescriptionMapper prescriptionMapper; @Resource private PrescriptionItemMapper prescriptionItemMapper; @Resource private DrugMapper drugMapper; @Override @Transactional(rollbackFor = Exception.class) public Long createPrescription(PrescriptionCreateDTO dto) { // 1. 生成处方主记录 Prescription prescription = new Prescription(); prescription.setPrescriptionNo(generatePrescriptionNo()); prescription.setConsultationId(dto.getConsultationId()); prescription.setDoctorId(dto.getDoctorId()); prescription.setPatientId(dto.getPatientId()); prescription.setDiagnosis(dto.getDiagnosis()); prescription.setStatus(PrescriptionStatusEnum.PENDING_AUDIT.getCode()); prescriptionMapper.insert(prescription); // 2. 批量插入处方明细 for (PrescriptionItemDTO itemDTO : dto.getItems()) { Drug drug = drugMapper.selectById(itemDTO.getDrugId()); if (drug == null) { throw new BizException("药品不存在: " + itemDTO.getDrugId()); } PrescriptionItem item = new PrescriptionItem(); item.setPrescriptionId(prescription.getId()); item.setDrugId(drug.getId()); item.setDrugName(drug.getName()); item.setSpec(drug.getSpec()); item.setPrice(drug.getPrice()); item.setDosage(itemDTO.getDosage()); item.setFrequency(itemDTO.getFrequency()); item.setDays(itemDTO.getDays()); prescriptionItemMapper.insert(item); } return prescription.getId(); } @Override @Transactional(rollbackFor = Exception.class) public void auditPrescription(PrescriptionAuditDTO dto) { Prescription prescription = prescriptionMapper.selectById(dto.getPrescriptionId()); if (prescription == null) { throw new BizException("处方不存在"); } // 状态机校验：只有待审核状态才能审核 if (!PrescriptionStatusEnum.PENDING_AUDIT.getCode().equals(prescription.getStatus())) { throw new BizException("当前状态不允许审核"); } prescription.setStatus(dto.getPassed() ? PrescriptionStatusEnum.AUDITED.getCode() : PrescriptionStatusEnum.REJECTED.getCode()); prescription.setAuditRemark(dto.getRemark()); prescriptionMapper.updateById(prescription); } private String generatePrescriptionNo() { return "RX" + System.currentTimeMillis() + RandomUtil.randomNumbers(4); } }

这段代码里有两个值得在答辩时展开的点。

第一是 @Transactional 注解。createPrescription中要插入主表数据和多条明细数据，必须放在同一个事务中。如果某一条明细插入失败，前面的主表插入也要回滚，否则会出现处方主记录存在但明细不完整的数据脏状态。老师问“为什么不拆开写”时，答案就是事务一致性。

第二是状态机的显式校验。auditPrescription方法中先检查当前状态是否为待审核，不是的话直接抛异常。这个简单的判断保证了状态流转的合法性，避免了已审核的处方被重复审核，或者已被驳回的处方又被误操作通过。

5.4 MyBatis-Plus Mapper 接口

// 文件路径：src/main/java/com/example/medical/mapper/PrescriptionMapper.java public interface PrescriptionMapper extends BaseMapper<Prescription> { /** * 查询患者处方列表（含明细） */ List<PrescriptionVO> selectPatientPrescriptionList(@Param("patientId") Long patientId); /** * 汇总各状态处方数量，用于后台统计 */ List<StatusCountVO> selectStatusCount(); }

对应的 XML 映射文件需要额外说明一下。用 MyBatis-Plus 做单表 CRUD 完全不需要写 XML，但复杂联表查询建议写 XML，而不是在 Service 层循环查库。一个典型的反例是：循环遍历 20 个处方，每个处方再查一次明细，造成 1 + N 查询问题。正确做法是用一条联表 SQL 一次性查出数据后，在 Java 内存中组装。

<!-- 文件路径：src/main/resources/mapper/PrescriptionMapper.xml --> <select id="selectPatientPrescriptionList" resultType="com.example.medical.vo.PrescriptionVO"> SELECT p.id, p.prescription_no, p.diagnosis, p.status, d.department_name, u.real_name AS doctor_name, p.create_time FROM t_prescription p LEFT JOIN t_doctor d ON p.doctor_id = d.user_id LEFT JOIN t_user u ON p.doctor_id = u.id WHERE p.patient_id = #{patientId} AND p.deleted = 0 ORDER BY p.create_time DESC </select>

6. 微信小程序端：首页、问诊、处方购药的实现思路

小程序端至少需要以下页面：

以“处方详情 + 去购药”页面为例，核心调用逻辑如下：

// 文件路径：pages/prescription/detail.js const app = getApp(); Page({ data: { prescriptionId: null, prescription: null, items: [], totalAmount: "0.00", }, onLoad(options) { this.setData({ prescriptionId: options.id }); this.loadDetail(); }, loadDetail() { wx.request({ url: `${app.globalData.baseUrl}/api/prescription/detail/${this.data.prescriptionId}`, method: 'GET', header: { Authorization: `Bearer ${wx.getStorageSync('token')}` }, success: (res) => { if (res.data.code === 200) { const detail = res.data.data; this.setData({ prescription: detail.prescription, items: detail.items, }); this.calcTotal(detail.items); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); } }, }); }, calcTotal(items) { let total = 0; items.forEach(item => { total += Number(item.price) * item.days * 1; }); this.setData({ totalAmount: total.toFixed(2) }); }, goToOrder() { const { prescription } = this.data; if (prescription.status !== 1) { wx.showToast({ title: '处方未通过审核，暂不可购药', icon: 'none' }); return; } wx.navigateTo({ url: `/pages/order/confirm?prescriptionId=${this.data.prescriptionId}`, }); }, });

这里有一个非常关键的前后端协作细节：前端不要自己算总价，总价应该由后端计算并返回。前端展示的金额仅作展示用，实际支付金额以后端计算为准。如果前端自己相加展示，而后端按数据库中的价格计算，两者很可能因精度处理不一致而出现分账问题。

本文示例中前端为了展示方便做了本地合计，但在实际项目中更稳妥的做法是：后端在处方详情接口里返回totalAmount字段，前端直接渲染。答辩时能指出“金额计算必须以后端为准，防止客户端篡改”，这会是一个加分回答。

7. 常见问题与排查思路

毕设阶段会遇到的问题，很多都是共性的。下面这张表是这类项目最常见的问题清单：

这里重点说两个高频坑。

第一个坑是小程序端请求后端接口时，出现“不在以下 request 合法域名列表中”。这是微信小程序开发最典型的报错之一。开发阶段可以在微信开发者工具的“详情 → 本地设置”中勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，即可正常调试。真机预览时同样需要开启调试模式。但要注意，正式上线时必须配置合法域名，且必须是 HTTPS。

第二个坑是后端时间字段返回给前端后少 8 小时。这是因为后端将时间按 UTC 存储，前端按东八区解析，或者反过来。解决方案是在后端配置统一处理时间序列化，把 LocalDateTime 转为yyyy-MM-dd HH:mm:ss格式的字符串返回，最简单的办法是在 Spring Boot 配置文件中设置 Jackson 的时间格式。

# 文件路径：src/main/resources/application.yml spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

8. 最佳实践与工程建议

8.1 前端请求封装统一处理

不要在每个页面都直接写wx.request。应该封装一个request.js工具类，统一处理 BaseURL、Token 注入、错误码拦截、401 跳转登录。这样后续改动后端地址或 Token 策略时，只需改一个文件。

// 文件路径：utils/request.js const BASE_URL = 'http://localhost:8080/api'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json', Authorization: `Bearer ${wx.getStorageSync('token')}`, }, success(res) { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }); reject(res.data); } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); }, }); }); } module.exports = { request, BASE_URL };

8.2 处方单号生成规则

处方单号不要使用自增 ID 对外展示。一是容易暴露数据量，二是不同表的 ID 可能重复。推荐使用“业务前缀 + 时间戳 + 随机数”的方式，比如RX + yyyyMMddHHmmss + 4位随机数。订单号可以用类似规则。

8.3 默认密码和初始化数据

数据库初始化时，要给医生、药师、管理员各准备一个测试账号。用户密码不要明文存储，统一使用 BCrypt 加密。如果觉得手动注册流程太慢，可以在项目启动时通过 DataInitializer 类自动创建管理员账号。

8.4 论文里的系统设计图

这类项目写论文时，导师通常需要看架构图、功能模块图、业务流程图、ER 图和时序图。这里有一个实用建议：用绘图工具画好图后，导出成图片插入论文即可。项目代码里不需要内嵌图表，但文档目录下建议保留所有设计图的源文件，方便后期修改。

8.5 演示前的准备工作

毕设答辩前一定自己完整走一遍演示流程。建议准备一份“演示脚本”，包括：用患者账号提交一个问诊、切换到医生账号接诊并开方、切换到药师账号审核，再回到患者账号完成购药。这五个步骤十分钟能讲完，但完整展示了闭环业务。如果把所有功能点平铺演示，反而显得没有重点。

9. 代码部署与启动要点

毕设系统通常需要在自己电脑上完整跑起来。下面给出一份最小启动指南。

9.1 后端启动

1. 创建数据库：`CREATE DATABASE medical_platform DEFAULT CHARACTER SET utf8mb4;` 2. 导入 `sql/medical_platform.sql` 脚本。 3. 修改 `application.yml` 中的数据库用户名密码。 4. 运行 `MedicalApplication.java` 的 main 方法。 5. 访问 `http://localhost:8080/doc.html`（如果集成了 Knife4j 或 Swagger，则可以查看接口文档）。 测试一个接口是否可用：

curl http://localhost:8080/api/user/info/{id} -H "Authorization: Bearer token"

如果返回 JSON 数据，说明后端启动成功。 ### 9.2 小程序端启动 1. 打开微信开发者工具，导入小程序项目目录。 2. 在 `utils/request.js` 中将 `BASE_URL` 改为后端的局域网地址，例如 `http://192.168.31.25:8080/api`。 3. 在开发者工具详情中勾选“不校验合法域名”。 4. 编译运行，进入登录页面。 需要注意：真机预览时，手机和电脑必须在同一局域网内，否则无法访问后端接口。这是联调中出现“真机请求失败”的最常见原因。 ## 10. 关于源码与进一步学习的建议 从一个开源毕设项目的角度，拿到源码后不要急着跑起来，先做四件事： 1. **看数据库脚本。** 认真读每张表的字段和注释，理解核心业务的建模思路。 2. **看状态字段。** 找到所有用了 `int` 状态字段的表，梳理状态之间的流转关系。 3. **看接口文档。** 如果项目里集成了 Swagger 或 Knife4j，把核心接口全部过一遍，记录每个接口的作用。 4. **改一个功能点。** 比如把“医生接诊后自动发送欢迎语”改成“医生接诊后发送一段项目自定义的内容”，通过改这段代码快速熟悉前后端交互。 真正拉开毕业生差距的不是代码量，而是能不能把业务逻辑讲清楚。在线问诊与电子处方流转平台这个选题，胜在业务链完整、角色分明、状态流转清晰。把数据库设计和几个核心接口的实现原理弄明白，答辩时基本能把老师的问题全部接住。 如果你是想快速开始，优先把患者端问诊和医生端开方这两个闭环跑通，再扩展药师审核、订单支付和后台管理。后面这几个模块其实是第一个闭环的复制和扩展，难度不会跳跃式上升。 祝各位顺利通过毕设。代码之外，把业务流程理解透，才是这个项目带给你最大的收获。建议收藏备用，做的时候遇到问题可以回来对照排查。