企业官网建设流程全解析

一、项目背景

传统的中医药服务往往分散在挂号、问诊、药材购买和健康知识等多个渠道中，用户需要在不同平台之间切换。杏林堂中医药服务平台将“找医师、预约、购买药材、查看物流、评价和交流”串联为完整业务闭环，并引入 AI 药性分析、智能推荐、药方检测和智能问答，为用户提供辅助性信息服务。

系统不是从零搭建，而是在已有通用后台骨架上进行领域化改造。改造时保留成熟的登录鉴权、统一响应、异常处理和后台权限体系，在此基础上新增中医药业务模块。这样既减少了对基础框架的破坏，也让开发重点集中在预约、订单、评价和 AI 等核心业务上。

需要特别说明的是：平台中的 AI 结果仅用于知识科普和辅助参考，不能替代执业医师的诊断、处方与用药指导。

二、技术选型

1. 后端技术

• Java 17、Spring Boot 3.3.0；
• MyBatis-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 setup>；
• Vite 负责开发与构建；
• 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，避免项目规模扩大后难以维护。

四、四类角色与双会话鉴权

系统包含四类角色：

1. 超级管理员super_admin：维护站点配置、模块开关和菜单体系；
2. 普通管理员admin：负责医师审核、药材、订单、预约、评价、资讯和论坛等运营工作；
3. 中医师business：维护个人资料和排班，处理预约，填写诊断意见并回复评价；
4. 普通用户user：预约就诊、购买药材、评价、发帖交流并使用 AI 功能。

项目沿用两套并行的 HttpSession 登录态：后台的超级管理员、管理员和中医师共用LoginInterceptor；前台普通用户由FrontLoginInterceptor单独校验。这样做的实际好处是后台工作台与用户前台可以同时保持登录，不会因为角色切换互相覆盖。

中医师入驻后还需经过管理员资质审核。账号状态与verify_status共同构成登录前置条件，未审核或审核未通过的账号不能进入医师工作台。

五、核心业务设计

1. 医师排班与预约

排班表以“医师 + 日期 + 上午/下午”为唯一维度，记录总号源和已预约数。用户选择排班后填写就诊人、联系电话和主诉症状，系统生成预约编号及就诊号序。

预约状态为：

待就诊 -> 已完成 -> 已评价 └----> 已取消

用户只能在符合规则的时间取消预约；医师完成接诊时必须填写诊断意见。预约成功会增加已约号源，取消后回滚数量，但原号序不再复用。

2. 中药商城与订单

药材信息不仅包含名称、图片、价格和库存，还包括别名、性味、归经、功效、用法用量和禁忌等领域字段。平台支持按克购买，订单明细会保存药材名称、规格、单价和封面快照，避免药材资料后续修改导致历史订单展示变化。

订单状态为：

待支付 -> 待发货 -> 已发货 -> 已收货 -> 已评价 └--------------------------------------> 已取消

待支付订单超过 15 分钟会自动取消并回滚库存。管理员发货时写入快递公司、单号和物流节点，用户确认收货后才能评价。

3. 统一评价

系统没有分别创建“医师评价表”和“药材评价表”，而是通过tcm_comment统一承载：

• target_type标识doctor或medicine；
• target_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 冲突。

八、项目亮点总结

1. 预约号源与药材库存均采用原子条件更新，具备基础并发安全能力；
2. 预约、订单和评价形成清晰状态机，非法状态不能跨级操作；
3. 四种角色职责明确，前台与后台登录态互不干扰；
4. 药材资料兼顾电商字段与中医药领域字段；
5. DeepSeek 输出采用 JSON 模式、失败重试、白名单校验和结果落库；
6. 前后台使用两套视觉体系，兼顾文化表达与管理效率；
7. 项目包含全量 SQL 和演示数据，便于部署、答辩和二次开发。

九、结语

杏林堂中医药服务平台的价值不只在于功能数量，而在于把预约、商城、履约、评价、内容和 AI 服务组织成可运行的业务闭环。对于类似的毕业设计或中小型业务系统，可以复用本文的领域拆分、状态机、原子更新、统一评价和 AI 结果治理思路，再根据实际场景扩展支付、消息推送、电子处方与审方等能力。