做毕业设计选“在线问诊与电子处方流转平台”这个方向最值得先弄清楚的一点是它不是做一个简单的聊天工具也不是只做一套药品展示页面而是要把“患者提问、医生接诊、开具处方、药师审核、处方流转到药店”这条完整链路在小程序端跑通。这类题目之所以受欢迎是因为它同时覆盖了微信小程序开发、后端接口设计、数据库建模、权限控制和业务流程状态机设计这几个关键点答辩时有东西可讲代码量也足够撑起一份完整的毕业设计。我建议先不要急着写代码先把这套系统的业务边界拆清楚。下面按我实际做过这类项目的顺序把选题定位、数据库设计、核心流程、代码骨架、部署联调和答辩准备完整过一遍。1. 这类毕业设计到底在做什么先说清楚系统边界1.1 不是问诊聊天室而是“问诊 处方 流转”的闭环很多同学看到“在线问诊”四个字第一反应是做一个即时聊天页面类似于微信聊天列表。这个方向不算错但如果只做到这一步系统深度不够答辩时也很难体现工作量。真正的核心在于“电子处方流转”这几个字。处方流转的意思是医生在线上给患者开具电子处方后这份处方不是停留在医生端而是可以流转到审核药师、流转到患者端、流转到线下药店或平台药房形成一个可供追溯的处方生命周期。所以整个系统至少要有这几个角色患者端微信小程序用户发起问诊、填写病情描述、查看医生回复、查看电子处方、凭处方购药。医生端小程序或管理后台接收问诊单、补充问诊信息、开具处方、查看历史患者。药师端审核医生开具的处方检查药品剂量、药物相互作用、患者过敏史等审核通过或退回。管理员端管理用户、管理药品目录、管理科室和医生信息、查看流转记录。这决定了你后面的数据库表、接口设计、页面跳转逻辑都要围绕状态流转来做而不是只在页面上堆功能。1.2 什么是“处方状态机”处方流转平台最常见的判断标准就是每一条处方记录是否有清晰的状态变化。一般来说至少需要这几个状态待医生开方问诊单创建成功医生尚未处理。待药师审核医生已开具处方等待药师审核。审核通过/已生效药师审核通过患者可以查看和流转处方。审核退回药师审核不通过需要医生修改或补充。已购药/已完成患者凭处方完成购药处方流转流程结束。已过期处方超过有效期自动失效。在数据库设计阶段你会用到一个prescription_status字段但在业务逻辑上我建议把它设计成状态机而不是随意改字符串。这样做的好处是前端可以根据状态渲染不同按钮后端接口可以根据状态拦截非法操作日志表里也能完整追踪每一条处方的流转历史。1.3 适合谁的选题工作量大概有多少这个题目更适合有过基础 Java/Spring 或 Node.js 经验的计算机专业学生。如果只学过前端也没有关系但你需要把后端部分尽量简化或者使用微信云开发来降低难度。工作量评估小程序端大约 12 到 18 个页面包括登录、首页、问诊单填写、医生列表、问诊详情、处方详情、购药订单、个人中心。后端接口大约 30 到 40 个覆盖用户、医生、问诊、处方、药品、订单、文件上传。数据库表大约 10 到 15 张核心表。后台管理端如果时间紧张可以用简单的 Web 页面也可以用 uni-app 写一个多端管理端。如果只是完成基础功能演示正常节奏是 4 到 6 周。如果你打算把接口、状态机、权限控制、部署全部做完整建议预留 7 到 8 周。2. 正式开发前先把环境、角色、权限和数据模型定下来2.1 技术选型方案对比我实测过几种常见组合下面直接给对比结果。技术组合前端后端数据库适合情况坑点微信原生 云开发微信小程序原生微信云函数云数据库新手、时间紧张、不想折腾服务器云函数冷启动慢复杂事务麻烦微信原生 Spring Boot微信小程序原生Spring Boot MyBatis PlusMySQL毕业设计常见结构清晰答辩好展开需要服务器或本地部署要处理跨域和 HTTPSuni-app Node.jsuni-app 一套代码多端Express / KoaMySQL/MongoDB想保留 Web 管理端或 App 端小程序原生组件能力兼容需要花时间微信原生 Django微信小程序原生Django REST FrameworkSQLite/MySQLPython 技术栈同学部署环境配置比 Java 多一点小坑我个人建议如果你是做传统的计算机毕业设计选“微信小程序原生 Spring Boot MySQL”这套资料多遇到问题容易搜索而且 MyBatis Plus 的代码生成器能省下大量重复写 CRUD 的时间。如果你想让答辩有亮点可以把管理后台也用 uni-app 来做这样同一套代码可以编译成 H5演示时直接用浏览器打开管理端效果会更好。2.2 开发者账号和工具准备在做代码之前先把这些准备好微信小程序开发者工具稳定版即可。一个小程序 AppID如果没有企业主体用个人主体也可以但个人主体下无法开通微信支付和部分医疗类目权限。毕业设计演示用个人主体通常够但上线受限。微信开发者工具里开启了“不校验合法域名”选项方便本地调试。后端开发环境JDK 8 或 11Maven 3.6MySQL 5.7 或 8.0Redis 可选用于 Session 或 Token 缓存。如果你的后端需要本地手机真机联调注意手机和电脑必须处在同一局域网并且后端接口地址要填电脑的局域网 IP不能填 127.0.0.1。2.3 数据库设计一张处方流转表怎么拆数据库设计是这类项目最容易被提问的部分。不要只设计一张order表把所有字段塞进去推荐拆成这些核心表user用户表保存 openid、昵称、头像、手机号、角色类型患者、医生、药师、管理员。doctor医生信息表关联 user 表包含科室、职称、简介、问诊价格、接诊状态。department科室表比如内科、外科、皮肤科。inquiry问诊单表包含患者、医生、病情描述、图片、问诊状态。prescription处方表关联问诊单、患者、医生、药师包含状态、总金额、有效期、审核备注。prescription_item处方明细表一个处方对应多个药品项包含药品名称、规格、数量、用法、用量。drug药品目录表包含名称、规格、生产厂家、库存、价格、处方药标记。order购药订单表对应用户凭处方购买药品。prescription_log处方流转日志表记录每一次状态变化和操作人。关键是在prescription表里加一个current_role或audit_level字段用来表示当前处方流转到哪个角色。否则多个角色同时操作时容易出现“医生看处方仍待审核药师显示已通过”的问题。实际开发时我一般会在状态机外层再加一张流水表只做状态变更记录不参与核心业务查询这样排查问题非常方便。2.4 登录授权真实微信登录和模拟登录都要做微信小程序里最常见的错误就是项目标题里提到的“小程序获取登录后的微信用户失败”。出现这种问题十有八九不是后端有问题而是前端调用wx.login获取 code再调用后端换取 openid 的链路没走通。正确流程是小程序端调用wx.login()获取临时 code。小程序端把 code 发送到自己的后端接口。后端调用微信的jscode2session接口用 code 换 openid 和 session_key。后端生成自定义登录态 token返回给小程序。小程序后续请求都带着 token后端通过拦截器验证。不要在客户端直接拿 openid 作为用户标识。openid 是敏感信息而且每次登录都需要后端换取不能在页面里硬编码。同时要给异常情况留退路很多毕业设计现场演示时网络环境不稳定微信 code 可能无效所以可以在后端接口里支持一个“测试模式”或“临时登录”接口固定返回一个测试用户的 token。这样演示时即使微信服务不可用系统页面还能正常流转。3. 前端页面和核心接口从问诊单到处方流转3.1 首页和问诊单填写页面首页不要做太复杂。我的习惯是顶部一个搜索框下面按科室分类再往下是推荐医生列表。科室数据从后端接口读取不要让前端写死。这样以后在管理后台里新增科室小程序端不用发版。问诊单填写页面有几个字段必须保留患者主诉必填限制最少 10 个字避免出现过于随意的问诊内容。病情描述选填但建议保留能提升演示时的完整度。图片上传支持上传病历、检查报告图片。这里推荐用微信云存储如果没有云开发也可以在后端做文件上传接口返回 URL 存到数据库。科室选择必填关系到医生分配逻辑。医生选择可以两步走先选科室再加载该科室下医生列表。问诊单创建成功后前端刷新为“待接诊”状态然后通过定时轮询或 WebSocket 获取医生回复状态。毕业设计用定时轮询就够了推荐每 5 到 10 秒拉一次接口不要用 1 秒否则后端压力大调试时日志也会被刷屏。3.2 医生端接诊与开方页面医生端和小程序一般是同一个小程序里的不同角色入口。登录后后端根据用户角色的不同返回不同的首页路径。医生首页显示“待接诊问诊单”点击进入后可以看到患者填写的主诉、病情描述和图片。医生有两个关键操作补充问诊如果患者信息不够医生可以在问诊单下方继续提问患者在小程序端看到追加问题并回复。开具处方填写药品明细。此时前端只需要收集数据不用判断药品是否合理合理性检查在药师端。开方页面我建议用动态表单。一个处方可能包含多个药品项每个药品项字段包括药品名称从药品目录中选择或手动输入规格数量用法口服、外用、静脉注射等剂量频次每日几次备注提交处方后后端创建prescription和prescription_item数据状态设为“待药师审核”同时写入日志表。3.3 药师审核页面权限控制和状态流转的关键药师端是整个系统最体现专业性的部分。药师进入审核页后看到的是待审处方列表点击某一条处方能看到完整的问诊信息和处方明细。审核页面至少要展示这些信息患者基本信息、过敏史如果有医生信息问诊信息药品明细列表每项药品的用法用量处方总金额历史处方记录药师操作只有两个按钮审核通过、退回。这里要注意退回处方时必须填写退回原因否则医生端不知道如何修改。审核通过后处方状态变成“已生效”患者端才能看到处方详情和购药按钮。3.4 患者端处方详情与购药流程当处方状态为“已生效”时患者端显示处方二维码或处方编号同时弹出“去购药”入口。购药流程可以有两种实现方式方式一平台内购药患者直接在系统内选择药房和药品生成订单并支付。这种方式需要对接支付个人小程序做不了所以在毕业设计里建议用“模拟支付”也就是点击提交订单后直接进入待收货状态。方式二处方流转到线下药房患者到药店后凭处方二维码购药。毕业设计里可以做一个“扫码验证”页面药师输入处方编号或扫描二维码系统校验处方状态后确认核销。我建议毕业设计里把两种方式都保留但演示时以方式二为主更能突出“流转”这个主题。4. 后端接口设计与状态机实现4.1 统一返回结构和登录拦截后端接口统一返回一个结构比如code、message、data这样小程序端封装公共请求方法时很简单。示例结构{ code: 0, message: success, data: {} }code为 0 表示成功非 0 表示失败。失败码可以从 1000 开始递增例如 1001 表示未登录1002 表示无权限1003 表示参数错误1004 表示状态不允许当前操作。登录拦截在 Spring Boot 里可以直接用拦截器实现。写一个TokenInterceptor从请求头里取token查询 Redis 或 JWT 校验后把用户信息放入ThreadLocal。所有需要登录的接口都经过这个拦截器管理后台接口再额外校验角色。4.2 处方状态流转如何写代码以 Java Spring Boot 为例核心逻辑可以分成三层Controller 层只做参数接收和结果返回。Service 层处理业务状态判断和流转。Mapper 层负责数据库操作。创建处方时的核心代码片段Service public class PrescriptionServiceImpl implements PrescriptionService { Resource private PrescriptionMapper prescriptionMapper; Resource private PrescriptionLogMapper prescriptionLogMapper; Override Transactional(rollbackFor Exception.class) public Long createPrescription(CreatePrescriptionDTO dto) { // 1. 校验问诊单状态 Inquiry inquiry inquiryMapper.selectById(dto.getInquiryId()); if (inquiry null || !WAIT_DOCTOR.equals(inquiry.getStatus())) { throw new BizException(1004, 问诊单状态不允许开方); } // 2. 创建处方主表 Prescription prescription new Prescription(); prescription.setInquiryId(dto.getInquiryId()); prescription.setPatientId(inquiry.getPatientId()); prescription.setDoctorId(dto.getDoctorId()); prescription.setStatus(WAIT_PHARMACIST); prescription.setTotalAmount(calcTotalAmount(dto.getItemList())); prescription.setValidityDays(7); prescriptionMapper.insert(prescription); // 3. 创建处方明细 for (PrescriptionItemDTO item : dto.getItemList()) { PrescriptionItem entity new PrescriptionItem(); entity.setPrescriptionId(prescription.getId()); entity.setDrugName(item.getDrugName()); entity.setSpecification(item.getSpecification()); entity.setQuantity(item.getQuantity()); entity.setUsageMethod(item.getUsageMethod()); entity.setDosage(item.getDosage()); entity.setFrequency(item.getFrequency()); prescriptionItemMapper.insert(entity); } // 4. 写入日志表 saveLog(prescription.getId(), CREATE, dto.getDoctorId()); return prescription.getId(); } }关键点有两个一是事务注解保证处方主体和明细要么同时成功要么同时失败二是状态检查每次流转前先查当前状态再做变更避免脏操作。4.3 药师审核接口的幂等处理药师审核时需要注意接口幂等。也就是同一条处方不能被重复提交“审核通过”。常见的做法是使用条件更新 SQL例如UPDATE prescription SET status APPROVED, pharmacist_id #{pharmacistId}, audit_note #{auditNote}, audit_time NOW() WHERE id #{prescriptionId} AND status WAIT_PHARMACIST受影响行数如果大于 0说明更新成功如果等于 0说明状态已经变化需要返回“该处方已被处理”。这种方式不需要额外加锁也能保证并发安全。4.4 文件上传接口患者上传病情图片时比较简单的方案是后端提供一个上传接口使用 OSS 或本地磁盘存储。如果使用本地存储要注意保存目录不能放在项目读取不到的临时目录。文件名要重新生成避免中文乱码和文件名冲突。返回给前端的 URL 要是可访问的静态资源路径。PostMapping(/upload) public RString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return R.fail(1003, 上传文件不能为空); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID() suffix; File dest new File(uploadDir, fileName); // 写入文件 file.transferTo(dest); String url /files/ fileName; return R.ok(url); }这里有个容易踩的坑Spring Boot 默认只允许 1MB 文件上传患者拍一张照片往往就超过 1MB。需要在配置文件里调大spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB4.5 微信支付和模拟支付在线问诊平台如果涉及付费问诊正式上线需要微信支付但个人主体的小程序无法开通。毕业设计里建议使用模拟支付。具体做法是用户点击“确认支付”后前端调用一个“创建支付订单”接口后端生成订单并把状态置为“已支付”然后跳转到成功页。答辩时如果被问到真实支付如实说明“微信支付需要企业资质演示时使用模拟支付流程生产环境可以替换为统一下单接口”即可。不要硬写一套没调通的支付代码反而容易被追问。5. 小程序端登录、部署与联调最容易翻车的几个环节5.1 获取用户手机号和头像要注意微信小程序的“获取用户头像和昵称”接口在基础库 2.21.2 之后改成了头像昵称填写能力不能再像过去一样直接弹出授权弹窗拿到完整信息。现在微信返回的是默认灰色头像和“微信用户”昵称。所以设计登录流程时建议不要强依赖微信授权。用户首次登录只拿 openid 作为账号唯一标识然后引导用户进入“个人资料完善”页面允许用户自己填写昵称和上传头像。这样既避免了基础库兼容问题也符合微信最新的用户隐私规定。5.2 request 请求封装与常见报错小程序端请求封装是整个前端项目的基建写不好后面所有页面都会卡。我一般会在utils/request.js里统一处理const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl url, method: method, data: data, header: { Content-Type: application/json, token: wx.getStorageSync(token) }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else if (res.data.code 1001) { // 未登录跳转登录页 wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); };常见的报错有这么几类request:fail域名不合法或本地服务未启动。开发者工具里勾选“不校验合法域名”同时确认后端服务在电脑上已经跑起来。net::ERR_CONNECTION_RESET真机调试时经常出现一般是手机和电脑不在同一局域网或者后端接口地址写成了 127.0.0.1。正确写法是改成电脑的局域网 IP。maximum setlocal recursion level reached这条大概率不是你的代码问题而是微信开发者工具的 bug重启开发者工具一般能解决。登录失败先看后端日志里有没有收到 code收到以后 jscode2session 是成功还是失败。大多数问题是 AppID 和密钥配置错误或 appid 不是本人的。5.3 上线发布的基本步骤虽然毕业设计不一定需要上线但很多同学会走到发布体验版这一步。基本流程在微信公众平台完善小程序信息类目建议选“医疗 互联网医院”或“工具 信息查询”。个人主体可选类目有限如果审核不通过可以选择不发布用体验版演示。后端接口必须是 HTTPS 且域名已备案。本地开发时可以关闭校验但体验版和线上版必须配置合法域名。在开发者工具中点击“上传”填版本号然后在公众平台版本管理里设为体验版。体验版二维码在“版本管理”页面可以找到。如果后端没有部署到服务器只在本地跑那么体验版无法使用。所以毕业设计如果要演示到手机端建议至少买一台最低配的云服务器或者用内网穿透工具临时开放接口。5.4 本地部署要注意的端口和跨域问题Spring Boot 默认端口是 8080小程序端请求时不会遇到浏览器跨域问题因为小程序不是浏览器环境不受 CORS 限制。但如果你的管理后台是 Web 页面就要在后端加 CORS 配置。跨域配置示例Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }需要注意的是如果开启了 allowCredentials(true)allowedOrigins 不能写*要用 allowedOriginPatterns。6. 小程序页面设计几个必须做好的业务页面6.1 患者端首页与问诊入口患者端首页建议包含这几块头部搜索框搜索医生、科室或药品名称。科室导航横向滚动的一级科室图标。医生列表展示医生姓名、职称、科室、问诊价格。快捷入口我的问诊单、我的处方、我的订单。这里有个小技巧医生列表接口后端返回字段时不要只返回医生姓名和头像还要返回一个inquiryCount或serviceCount字段表示该医生累计服务次数。这样前端可以在医生卡片上显示“已服务 xxx 次”增强页面可信度也方便答辩时展示接口联调效果。6.2 问诊单详情与聊天记录问诊单详情页模板可以参考微信聊天界面左边是患者消息右边是医生消息。但底层不是真正的 WebSocket而是用问诊回复接口轮询获取。后端设计一张inquiry_reply表每次小程序端定时拉取时只返回增量数据。增量判断可以用reply_id lastId避免每次全量拉取聊天记录。6.3 处方详情页与二维码展示处方详情页是整个系统里最值得精细打磨的页面也是答辩现场最容易出彩的地方。我建议至少包含处方编号和状态标签。患者姓名、年龄、性别。诊断结果或主诉摘要。药品明细表格。开具医生信息、审核药师信息。处方有效期。二维码或条形码区域。“去购药”或“核销”按钮根据状态动态显示。二维码可以用weapp-qrcode组件生成也可以在后端生成二维码图片返回给前端。建议后端生成这样二维码内容是一个短链接点击后跳转到处方详情页。6.4 管理后台页面管理后台如果时间有限不用做太复杂。我的建议是做一个单页 Web 应用菜单包含用户管理用户列表、启用/禁用。医生管理审核入驻、设置接诊状态、查看接诊记录。药品管理药品 CRUD、库存管理。问诊管理所有问诊单列表和详情。处方管理处方列表、状态筛选、流转日志。数据统计问诊数量、处方数量、药品销量。数据统计页不需要做图表放一个简单的数字卡片列表就行。如果学生基础好一点可以集成 ECharts 画一个柱状图展示近 7 天问诊数量变化。7. 测试用例和答辩准备7.1 基础功能测试清单在答辩前至少把下面这些场景走一遍患者新注册、完善资料、登录态是否持久。患者创建问诊单后医生端能否看到待接诊列表。医生补充问诊后患者端能否正常收到回复。医生开方后处方状态是否变为待药师审核。药师审核通过后患者端能否看到处方详情。药师审核退回后医生端能否看到退回原因并修改。处方过期后状态是否正确更新。患者模拟支付后后台订单列表是否有记录。管理员禁用某个医生后该医生是否无法接诊。没有登录的用户访问需要登录的页面是否被拦截。这些场景如果都能跑通整个系统的逻辑就立住了。7.2 答辩时容易被问的问题导师和评委通常会围绕这几个方向提问你需要提前准备为什么选择微信小程序而不是 App后端为什么选 Spring Boot有没有考虑过 Node.js 或云开发电子处方流转过程中如何保证数据安全和患者隐私处方状态机是怎么设计的并发条件下如何保证状态一致如果药师审核和患者购药同时发生怎么避免处方被重复使用系统支持多大规模并发你做过性能测试吗前几个问题你都能从设计文档里找到答案。最后一个问题如果没做过性能测试可以直接回答“本系统定位是毕业设计演示没有进行大规模并发测试但接口设计上考虑了幂等性和状态校验”。不要硬说自己做过压测。7.3 论文和答辩 PPT 怎么写论文结构可以参考绪论背景、意义、国内外现状。相关技术介绍微信小程序、Spring Boot、MySQL、Redis。需求分析角色分析、业务流程、功能需求。系统设计架构图、功能模块图、数据库设计、状态机设计。系统实现分前端和后端写核心功能实现。系统测试测试环境、测试用例、结果分析。总结与展望。答辩 PPT 控制在 12 到 15 页先讲背景和业务流程再重点讲状态机和数据库设计最后现场演示。不要把代码贴到 PPT 上评委想看代码时会让你打开项目现场看。8. 几个提升质量和观感的小建议8.1 用真实数据填充系统演示时最尴尬的情况是系统里没有数据页面一片空白。开发完成后可以写一个简单的 SQL 脚本插入几个科室、十来个医生、几十种常用药品以及几条不同状态的演示问诊单。这样一打开系统页面就饱满很多。8.2 使用微信开发者工具的云开发时注意冷启动如果是用云开发作为后端有一个比较头疼的问题是冷启动。每次调用云函数后如果一段时间没人调用再次调用时云函数需要冷启动耗时可能达到 2 到 3 秒。解决方法是日志里看到冷启动时间长不用太慌答辩前先把系统页面点一遍让云函数预加载正式演示时就会流畅很多。8.3 尽量用真实拟真数据避免测试字样把患者和医生数据尽量做成真实姓名风格比如“张伟医生”“李婷患者”不要出现“测试用户 1”“测试医生 2”。细节会影响答辩观感。8.4 把关键表结构图打印或提前准备好答辩现场经常会问到“这两张表是什么关系”“处方明细为什么单独拆表”。如果你提前准备好一张数据库关系图可以直接应付这类问题。不一定要用专业工具画用 Navicat 的 ER 图导出或者总结成表格都可以。这套系统真正做完收获最大的不是会写几个小程序页面而是理解了一个带状态流转的业务系统如何从前端交互、后端接口、数据库设计三个层面配合。在线问诊、申请开方、药师审核、处方流转、购药核销只要把这条链路的状态机想清楚后面加功能只是工作量问题不会再有方向性困惑。如果要排优先级先把处方状态机和角色权限做扎实再完善页面视觉效果。一个能稳定跑通“患者申请 - 医生开方 - 药师审核 - 患者购药”的系统远比一个界面花哨但流程混乱的 Demo 更能得分。