一、项目背景传统的中医药服务往往分散在挂号、问诊、药材购买和健康知识等多个渠道中用户需要在不同平台之间切换。杏林堂中医药服务平台将“找医师、预约、购买药材、查看物流、评价和交流”串联为完整业务闭环并引入 AI 药性分析、智能推荐、药方检测和智能问答为用户提供辅助性信息服务。系统不是从零搭建而是在已有通用后台骨架上进行领域化改造。改造时保留成熟的登录鉴权、统一响应、异常处理和后台权限体系在此基础上新增中医药业务模块。这样既减少了对基础框架的破坏也让开发重点集中在预约、订单、评价和 AI 等核心业务上。需要特别说明的是平台中的 AI 结果仅用于知识科普和辅助参考不能替代执业医师的诊断、处方与用药指导。二、技术选型1. 后端技术Java 17、Spring Boot 3.3.0MyBatis-Plus 3.5.7负责常规 CRUD、分页和条件更新MySQL 8使用 InnoDB、utf8mb4 字符集Spring Validation 进行参数校验Spring Security Crypto 的 BCrypt 处理密码HttpSession 拦截器维护两套登录态Knife4j 生成和调试接口文档Java 17 HttpClient 直连 DeepSeek Chat API。2. 前端技术Vue 3使用script setupVite 负责开发与构建Vue Router 维护路由和角色守卫Pinia 保存登录态、AI 面板状态和药方暂存数据Axios 封装统一请求Element Plus 主要用于后台管理ECharts 展示数据看板和药性关系图WangEditor 用于知识资讯等富文本内容维护。三、总体架构与模块划分系统采用典型的前后端分离结构。浏览器通过 Vue 前端访问 Spring Boot REST 接口后端完成身份校验、业务处理和数据持久化再以统一 JSON 结构返回结果。后端按业务域划分包而不是把所有 Controller、Service 和 Mapper 淩乱地堆在一起com ├─ common 通用返回、异常、拦截器和工具 ├─ god 超级管理员配置与模块开关 ├─ admin 管理员账号和权限 ├─ business 中医师账号、资质和专业资料 ├─ user 普通用户与个人中心 ├─ appointment 排班与预约 ├─ medicine 药材、订单与物流 ├─ comment 药材评价和就诊评价 ├─ ai 四项 AI 能力及调用记录 ├─ article 知识资讯 ├─ forum 中医交流 └─ web 前台聚合接口这种划分的优势是模块边界清楚。例如预约逻辑只需要重点关注appointment订单问题主要定位到medicine避免项目规模扩大后难以维护。四、四类角色与双会话鉴权系统包含四类角色超级管理员super_admin维护站点配置、模块开关和菜单体系普通管理员admin负责医师审核、药材、订单、预约、评价、资讯和论坛等运营工作中医师business维护个人资料和排班处理预约填写诊断意见并回复评价普通用户user预约就诊、购买药材、评价、发帖交流并使用 AI 功能。项目沿用两套并行的 HttpSession 登录态后台的超级管理员、管理员和中医师共用LoginInterceptor前台普通用户由FrontLoginInterceptor单独校验。这样做的实际好处是后台工作台与用户前台可以同时保持登录不会因为角色切换互相覆盖。中医师入驻后还需经过管理员资质审核。账号状态与verify_status共同构成登录前置条件未审核或审核未通过的账号不能进入医师工作台。五、核心业务设计1. 医师排班与预约排班表以“医师 日期 上午/下午”为唯一维度记录总号源和已预约数。用户选择排班后填写就诊人、联系电话和主诉症状系统生成预约编号及就诊号序。预约状态为待就诊 - 已完成 - 已评价 └---- 已取消用户只能在符合规则的时间取消预约医师完成接诊时必须填写诊断意见。预约成功会增加已约号源取消后回滚数量但原号序不再复用。2. 中药商城与订单药材信息不仅包含名称、图片、价格和库存还包括别名、性味、归经、功效、用法用量和禁忌等领域字段。平台支持按克购买订单明细会保存药材名称、规格、单价和封面快照避免药材资料后续修改导致历史订单展示变化。订单状态为待支付 - 待发货 - 已发货 - 已收货 - 已评价 └-------------------------------------- 已取消待支付订单超过 15 分钟会自动取消并回滚库存。管理员发货时写入快递公司、单号和物流节点用户确认收货后才能评价。3. 统一评价系统没有分别创建“医师评价表”和“药材评价表”而是通过tcm_comment统一承载target_type标识doctor或medicinetarget_id指向被评价对象source_id指向预约或订单(target_type, source_id)唯一索引保证一次业务只能评价一次score_json保存多个分项评分支持匿名、图片、回复和显示状态。评价保存后系统重新计算目标对象的平均分和评价数量并回写医师资料或药材信息列表查询时无需每次实时聚合整张评价表。六、数据库设计要点数据库共包含系统管理、用户医师、预约排班、商城订单、统一评价、AI、内容互动和系统支撑等多个业务域。核心表之间的关系如下business_user 1 --- n doctor_schedule business_user 1 --- n doctor_appointment n --- 1 user_info user_info 1 --- n medicine_order 1 --- n medicine_order_item medicine_info 1 --- n medicine_order_item tcm_comment n --- 1 user_info设计中主要采用了以下策略所有核心表包含主键、创建时间、更新时间和状态字段订单明细使用数据快照保证历史记录稳定号源与库存采用数据库条件更新避免并发超卖多步写入使用事务任一环节失败即整体回滚AI 结果落库方便缓存、复用和后台审计统一文件表管理头像、药材图片、资讯封面和评价图片。七、前端改造前后台视觉分离后台继续使用 Element Plus以高信息密度和操作效率为主前台则采用独立的中医药设计系统。主色为墨绿强调色为朱砂背景模拟宣纸质感标题使用宋体卡片采用细描边、低圆角和无阴影设计。前台改造并不是简单替换颜色而是依据静态原型重新组织 DOM、类名、间距和组件结构。公共样式集中在tcm.css页面独有样式留在组件的style scoped中。通过body.web-theme控制主题变量仅前台覆盖 Element Plus 浮层样式从而避免影响后台页面。这个项目中的一条重要经验是设计系统必须有单一来源。若各页面分别复制按钮、卡片和表单样式很快就会出现视觉漂移和 CSS 冲突。八、项目亮点总结预约号源与药材库存均采用原子条件更新具备基础并发安全能力预约、订单和评价形成清晰状态机非法状态不能跨级操作四种角色职责明确前台与后台登录态互不干扰药材资料兼顾电商字段与中医药领域字段DeepSeek 输出采用 JSON 模式、失败重试、白名单校验和结果落库前后台使用两套视觉体系兼顾文化表达与管理效率项目包含全量 SQL 和演示数据便于部署、答辩和二次开发。九、结语杏林堂中医药服务平台的价值不只在于功能数量而在于把预约、商城、履约、评价、内容和 AI 服务组织成可运行的业务闭环。对于类似的毕业设计或中小型业务系统可以复用本文的领域拆分、状态机、原子更新、统一评价和 AI 结果治理思路再根据实际场景扩展支付、消息推送、电子处方与审方等能力。