可人儿黄同学先提个醒：别把“在线问诊挂号开药系统”当成一个简简单单的预约小程序来做。它表面上是挂号、聊天、下单、支付几个页面拼起来，实际跑一遍患者流程你就知道，这里面的角色关系、状态流转和数据一致性，比普通电商项目复杂得多。这篇文章不会停留在“我搭了个Spring Boot/uni-app能跑”这种层面，而是把这类系统真正要面对的业务闭环、工程骨架和踩坑点拆开讲清楚，适合正在做毕设、课设，或者打算认真做一个医疗类微信小程序全栈作品的同学参考。
1. 先拆业务闭环：这个系统到底要管多少件事
1.1 一次完整就诊流程是怎么串起来的
在线问诊挂号开药系统，名字看起来长，拆开其实是三个相对独立又有强关联的环节。患者进小程序第一眼看到的可能是医生列表、科室分类、排班时间；但背后的流程是从“选择医生”开始的：选定科室 -> 查看医生排班 -> 选择时间段 -> 提交挂号信息 -> 支付挂号费 -> 生成挂号记录 -> 进入候诊/问诊状态。问诊结束后，医生根据病情描述和检查结果判断是否需要开药；如果需要，就进入开方环节：创建处方、添加药品、填写用法用量、提交药师审核（如果业务要求的话）；患者收到处方后确认并支付药品费用，系统再进入配药发货流程。
这三个环节不是孤立的数据表，而是共享同一条“用户—就诊记录”主线的连续状态机。很多新手做这类项目时最常见的失误，就是把挂号记录、问诊记录、处方记录各建一张表，彼此之间没有外键关联，也没有状态字段。结果就是患者明明已经退号了，医生还能给他开处方；或者问诊都结束了，但挂号状态还是“待就诊”。所以做项目的第一步不是写登录注册，而是先把状态流转梳理清楚。
我建议你画一张简单的状态表，至少覆盖四个核心对象：预约单、问诊单、处方单、订单。每个对象都需要有自己的生命周期。预约单可以是“待支付 -> 已支付/待就诊 -> 就诊中 -> 已完成”或“已取消”；处方单则是“草稿 -> 待审核 -> 已通过 -> 已取药/已发货”等。状态机定好了，后端接口的权限判断就顺了：某状态下允许谁调用什么接口，写在代码里绝不互相矛盾。
1.2 和普通商城系统最本质的区别在哪里
如果只说“用户下单、支付、发货”，那这跟商城确实像。但医疗类系统有两点是商城远不能比的。
第一，数据正确性直接和人身安全绑定。处方里的药品名称、规格、剂量、频次错了，不是退个货就能弥补的。商城里库存少一件，后面补货就行；处方里剂量少了单位，赔不起。所以在后台接口层面，医生创建处方时必须联动药品表的基本信息，而不是让前端手填一个药品名字。药品名称、厂家、规格、剂型、库存量、单价，这些基础数据必须落库并由后端校验。
第二，权限边界要细得多。一个普通商城系统通常就三种角色：管理员、商家、用户。问诊系统至少得有患者、医生、药师（若有）、管理员这四类。医生能查看患者提交的病历资料，但患者不能随意查看其他患者的问诊记录；医生能修改自己的排班和擅长领域，但不能动药品库存；药师能审核处方，但不应直接改药品信息。这些如果不能通过后端统一做权限判断，前端页面隐藏按钮根本没有安全保障。
所以我的建议是：先把这些“业务规则”用自然语言列一遍，再去建表写接口。比如“患者提交挂号的医生必须处于可预约状态”“医生只能给处于‘就诊中’状态的问诊单开药”“用户取消订单后库存必须回补”。每一条规则背后都对应一个后端校验逻辑，这类项目做完之后你会发现，难点从来不是某个框架的API不会调，而是业务规则有没有覆盖完整。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型推导：为什么是 uni-app、Python、微信小程序这个组合
2.1 前端用 uni-app，是为了给“多端”留后路
在做这类项目时，前端框架的选择很关键。如果目标只做微信小程序，你用原生微信小程序开发也可以，代码写起来更直接，也没有跨端编译的中间层问题。但 uni-app 的好处在于：同一套 Vue 代码，可以编译到微信小程序、App、H5 等多个端。很多门诊项目需要同时出“医生端App、患者小程序、管理后台网页”的演示效果，用 uni-app 一套代码至少能同时覆盖小程序和H5，省下大量重复开发时间。
uni-app 的组件体系、页面路由、uni.request 接口，和原生小程序习惯有差异，但它底层最终还是编译成微信小程序原生语法。只要你在 HBuilderX 里跑过“运行到小程序模拟器”，就会发现页面反应会有几十毫秒的编译延迟，这正常；真正要注意的是别在代码里写浏览器专用 API，比如 window、document，小程序端是不存在的。路由传参也要注意，uniapp 的 uni.navigateTo 里通过 url 传对象时，需要先用 encodeURIComponent(JSON.stringify(obj)) 序列化，接收时再 decodeURIComponent，否则参数会被截断，这就是“uniapp获取路由参数”最常见的坑源。
如果你想做的是一个“演示起来流畅、视觉完整、答辩或交付时有真实感”的系统，uni-app 是不错的底盘。Vue 语法本来就是很多前端同学的舒适区，生态里关于选择器、表单校验、UI 库的现成方案也比较充足。尤其医疗系统里有大量表单页，比如挂号信息、患者主诉、收货地址、用药反馈，uni-app 里你可以自己封装多个带校验的表单组件，配合选择器组件做级联，体验会比小程序的原始 picker 灵活很多。
2.2 Python 后端为什么常用 Flask 而不是 Django
Python 后端在这个项目里最常见的两个选择就是 Flask 和 Django。如果你从零开始、想尽快看到接口效果，我推荐 Flask。它是微框架，启动一个服务只需要几行代码，开发时随时可以改 py 文件并重启，目录结构也自由。医疗问答、聊天记录这类接口，用 Flask 的蓝图分一下模块，业务逻辑放在 service 层，代码量并不大，反而好控制。
Django 的优势是自带 Admin 后台、ORM、认证、Admin 可视化，适合快速生成管理界面的场景。门诊系统确实有后台管理需求——管理医生排班、维护药品库、查看订单记录——Django Admin 几乎零成本给你一套可用的后台。但是 Django 的项目结构和约定较重，很多第一次做全栈项目的同学容易迷失在 settings、app、migration 这类目录里，反而拖慢进度。如果你工期紧张或本身是前端背景，Flask + SQLAlchemy 更友好。
我个人更推荐的做法是：核心后端使用 Flask 提供 JSON API，管理后台前端用 uni-app 的