企业官网建设流程全解析

1. 项目概述：一套带“推荐算法”的诊所管理系统到底在解决什么问题

先说个背景，我最近一直在琢磨私人诊所的信息化方案，接了这样一个项目：给一家连锁私人诊所搭建一套内部管理系统，标题写得很直白——企业级协同过滤算法私人诊所管理系统，技术栈固定是SpringBoot+Vue+MyBatis+MySQL。这系统不是简单的CRUD，它最大的亮点是集成了协同过滤推荐算法，会给患者推荐合适的医生、针对既往病史推荐检查项目和常用药品。整套源码是完整版的，从前端页面到后端接口再到数据库脚本全部包含，拿来就能跑，稍微改改就能对接真实业务。

很多朋友一看“企业级”三个字觉得膨胀，但实际上私人诊所这个场景真的很需要一套合规、可扩展的管理系统。私人诊所和公立医院不一样，没有庞大的信息科团队，预算有限但又想规范业务流程。既要管挂号、病历、收费，又希望能通过数据知道“哪些患者常常一起来的”“哪个医生擅长处理哪类症状”，这时候协同过滤算法就有用武之地了。它用起来不需要特别深的算法功底，只要数据表结构合理、评分或行为日志能积累起来，就能跑出靠谱的推荐结果。

这个项目适合什么人参考？我觉得有三类人最合适。第一类是Java全栈开发者，想找一个SpringBoot+Vue前后端分离的完整企业级项目练手，特别想看看协同过滤在业务里怎么落地实现；第二类是软件工程专业的学生，做毕业设计或者课程项目，需要一套功能完整、架构清晰、能讲清楚业务亮点的系统；第三类是私人诊所的经营者或者医疗信息化从业者，想了解一套轻量级诊所管理系统需要设计哪些模块，数据怎么组织，算法怎么和业务结合。

说白了，标题里提到的每一个技术点都不是摆设。SpringBoot负责后端接口的高效开发和稳定运行，Vue负责前端交互体验，MyBatis把数据库操作做到透明可控，MySQL存所有业务数据，协同过滤算法则把“死数据”变成“活推荐”。整套系统做下来，既能应付日常诊所的复杂管理需求，又能在面试或者答辩时讲出一个有深度的技术亮点。

我这次就把整个系统的核心设计、数据库建模、协同过滤实现、环境搭建和常见坑一次性拆开聊清楚，给后面要做同类项目的朋友一条可以直接走的路。

2. 核心需求与技术选型：为什么是这套架构，协同过滤用在哪儿

2.1 私人诊所的业务流程和管理痛点

私人诊所的业务流程看着简单，实际跑起来很杂。患者到店，先挂号或预约，然后分诊，见到医生之后产生病历记录，医生开处方，患者去药房取药或者做检查项目，最后收费结账。如果诊所还有会员制度，就得额外维护患者档案、积分、复诊提醒。这些业务串起来，如果全靠纸质登记或者Excel表格，很容易出问题：病历翻不到、收费对不上、患者信息重复、医生排班全靠喊。

管理层的诉求更具体。他们想知道哪些患者是高频客户，哪些药品库存周转快，哪个医生的复诊率和患者满意度高。但传统Excel很难把这些数据关联起来。这套管理系统的核心任务就是把所有业务环节线上化，让每一笔挂号、每一次开药、每一份病历都落库，同时把数据之间的隐含关系挖掘出来，辅助诊所做经营决策。

所以项目不是“为了管理系统而管理系统”，而是针对私人诊所特有的高频复诊、熟人医疗、药品库存小但流转快这些特点去设计。协同过滤算法在这里的作用，是把“人和人之间的选择相似性”提炼出来，比如A患者和B患者在既往就诊记录上高度相似，那B患者买过的一款维生素，A患者有较大概率也需要，系统就可以在医生开药或者患者端App上做提醒。

2.2 技术选型分析：SpringBoot、Vue、MyBatis、MySQL各自承担什么职责

这套系统选择SpringBoot作为后端框架，在当下是非常成熟稳重的方案。SpringBoot最直接的好处是自动配置，省去了一大堆XML配置的麻烦，内嵌Tomcat之后，打包成JAR就能启动。对于诊所管理系统这种典型的业务系统，SpringBoot的生态非常完善，要做权限控制就接Spring Security或Shiro，要做定时任务就接Quartz，要做接口文档就接Swagger或Knife4j，每个环节都有对应的成熟方案。

Vue作为前端框架，理由也很明确。项目用的是Vue2生态加Element UI组件库，这套组合在后台管理系统里的普及率极高，表格、表单、弹窗、菜单布局这些组件开箱即用。更重要的是Vue的双向数据绑定让表单联动、患者信息回填、药品库存联动这些交互写起来非常顺手，前端代码组织上按组件拆分，维护成本也不高。

MyBatis则是持久层框架，相比Spring Data JPA，它的SQL可控性更强。业务系统里经常有复杂的多表关联查询和统计SQL，比如统计某个时间段内每个医生的接诊量、某个药品的消耗趋势，这些用MyBatis直接写XML里的SQL，非常直观，排查问题也方便。再加上MyBatis的代码生成工具（比如MyBatis Generator），表结构定了以后，实体类、Mapper接口、XML映射文件都可以快速生成，开发效率提升明显。

MySQL选型更不用多说，轻量、开源、稳定，小型企业级项目首选。诊所系统的数据量，日门诊量几百人次，药品几千条，病历一年几万条，在MySQL上完全毫无压力。配合索引优化和正确的SQL写法，查询性能完全够。

2.3 协同过滤算法的引入动机与适用场景

协同过滤算法是这套系统区别于普通管理系统的最大亮点。一般在管理系统里面谈算法很罕见，因为多数人觉得管理系统就是增删改查。但这个项目确实挖出了一个真实需求：推荐医生、推荐检查、推荐用药。

先理清协同过滤的两条路。一种是基于用户的协同过滤（UserCF），核心思想是找到与你偏好相似的用户，把相似用户喜欢的东西推荐给你。另一种是基于物品的协同过滤（ItemCF），核心思想是分析物品之间的关联性，买了A物品的人常常也买B物品，那就把B推荐给现在看A的人。诊所系统里，我更推荐UserCF作为主推荐链路，因为患者个体差异比物品差异更值得关注。两个患者只要年龄相仿、症状描述接近、历史用药相似，那么他们的下一步就诊选择大概率也存在共性。

举一个具体场景。某患者因为长期失眠来诊所就诊，系统拉取他的历史病历和用药记录，在患者库中寻找相似度最高的若干名患者。系统发现那些相似患者中有八成都在复诊时同时开了安神类中成药和维生素B族补充剂，而当前患者的处方里只开了中成药，这时候协同过滤算法就会产生一个补充药品的推荐建议，推送给医生端作为参考。

这就是协同过滤在业务里的实际价值。它能跨病历记录找出容易被忽略的关联，辅助医生提供更周全的诊疗方案，同时提升诊所的单客消费金额和患者满意度。

2.4 功能模块全景：从挂号到数据统计

一套完整诊所管理系统应该有清晰的模块边界。我按实际业务把系统拆成了这样几个大模块：

每个模块不是孤立存在的，挂号关联医生排班和患者档案，病历关联挂号单，处方关联病历和药品库存，推荐算法关联患者、病历、处方、药品字典。整套系统的数据流是一环扣一环的，表单数据的录入会影响库存数量，患者的行为累积会影响推荐结果。

这种模块化的好处是：后续要扩展功能，比如增加微信预约、电子病历上传，只需要在对应的模块边界上开发，不会动到别的部分。

3. 数据库与算法模型：五张核心表如何支撑协同过滤

3.1 患者、病历、处方、药品、推荐记录的数据模型设计

协同过滤算法能不能跑起来，一半靠数据质量，一半靠表结构设计。很多新手最爱犯的错是忽略了数据间的关系，比如把药品名直接存在处方里而不关联药品字典表，这样做出来的系统没法做统计分析，更没法给推荐算法提供干净的输入。

这个项目的表结构设计用了典型的第三范式加适度的冗余设计。患者信息表（patient_info）存的是患者基础资料，包括姓名、性别、年龄、联系电话、过敏史、会员等级等。病历表（medical_record）每次就诊生成一条主记录，存患者ID、接诊医生ID、主诉、诊断结果、就诊时间。处方表（prescription）挂在病历之下，一张病历可以开多张处方。处方明细表（prescription_item）是真正连接药品的地方，存药品ID、数量、用法用量。

这里最关键是药品字典表（drug_info）和推荐结果表（recommend_result）的设计。药品字典表独立出来的好处是药品的基础信息如名称、规格、厂家、售价都在一处维护，处方里只存药品ID，要查药品信息再JOIN。推荐结果表则专门存放算法算出来的推荐数据，字段包括患者ID、推荐类型（1表示医生，2表示药品，3表示检查项目）、推荐目标ID、推荐分值和生成时间。这样把计算结果从业务表中分离出来，避免算法每次执行都要临时算一遍，性能更好，也方便业务端直接查询展示。

3.2 基于患者行为构建“用户–物品”评分矩阵

协同过滤算法最核心的输入是评分矩阵。传统的评分矩阵在电商里是用户对商品的打分，但在诊所系统里没有“给医生打星”这种现成数据，所以必须从行为记录中构造隐式评分。

我采用的规则是：把每个患者（用户）对每个药品（物品）的使用频次和用药时长换算成分值。比如某患者在过去180天内开过某种药品3次，每次疗程是7天，我就可以给这个“患者-药品”的评分记为3×1.2（1.2是一个疗程加权系数），如果连续两次开同一种药说明依从性好，再加0.5系数。最终所有评分落在一个稀疏矩阵里。

矩阵的规模和稀疏度需要心里有数。假设诊所系统里有2000个患者、800种药品，那矩阵就是2000×800的规模，共160万个格位，但实际有行为记录的可能只有10%，也就是16万个非零格位。这种稀疏度用协同过滤算法来跑是非常合适的，既不会稀疏到无法计算相似度，也不会稠密到计算量爆炸。

由于数据是稀疏的，我用了基于物品的协同过滤（ItemCF）作为药品推荐的主算法，因为物品之间的共现矩阵比用户之间的相似度矩阵要细密得多。在2000个患者的前提下，任意两种药品被同一患者开过的概率比两个患者有完全相同病史的概率高不少，所以ItemCF产生的结果更稳。

3.3 相似度计算与推荐生成的算法流程

具体实现分成四步。

第一步是构建物品共现矩阵。遍历所有处方明细记录，统计所有药品对（drugA，drugB）在同一个患者历史中出现过的次数。举个例子，患者1开过药A和药B，药品对AB的共现次数就加1；患者2也开过药A和药B，那AB共现次数变成2。这个共现次数还需要做归一化处理，除以A的总出现次数的平方根，得到最终相似度。

第二步是计算物品相似度矩阵。每两个药品的相似度sim(A,B) = cooccur(A,B) / sqrt(count(A) × count(B))，这本质上是余弦相似度。归一化之后，相似度就落在了0到1之间。我自己的经验是，某两种药品的相似度大于0.3就有推荐价值了，再低的话噪音就太大。

第三步是生成推荐列表。对目标患者P，找出他历史开过的药品集合S。对S中的每个药品A，遍历药品相似度矩阵，把与A相似的前N个候选药品找出来，按加权分数排序：score(B) = Σ sim(A,B) × weight(A)，权重就是患者历史上对药品A的使用频次。这里要注意的是，患者已经用过的药品必须在候选集中排除，不然推荐就失去意义了。

第四步是落库并展示。把算好的推荐药品按分数排序后写入recommend_result表，医生端在开处方时，页面上的“推荐关联用药”区域直接查这张表展示。不用每次前端请求都现场跑算法，这样响应快，也方便记录算法效果。

3.4 冷启动与算法兜底：新患者、新药品怎么处理

协同过滤算法最怕冷启动，就是系统里没有足够历史数据的情况。新患者一条就诊记录都没有，矩阵里他没有评分数据，算法算不出来相似物品，推荐就直接空掉了。新药品刚入库还没人开过，它和其他药品的共现次数全是0，也很难进入推荐候选集。

处理冷启动的思路是分层兜底。新患者没有历史用药的情况下，推荐策略退化成“热门推荐”，也就是直接推荐诊所里开药频次最高的前10种药品，这个逻辑用一条SQL按处方明细分组统计就能搞定。等患者有了一次就诊记录之后，就可以启用协同过滤算法来推荐。

新药品的处理更简单。新药品入库时，我们根据它的药品分类和功效标签，从同类药品里借用推荐关系。比如新进一款感冒灵颗粒，分类属于“解热镇痛类”，那原本感冒类药品之间的相似关系可以先平移给新药品，等它积累了一定处方量之后再回归算法计算。

这套兜底机制非常重要。没有它，算法在冷启动阶段基本是白搭。现在很多推荐系统在线上遇到新用户新物品都会走这个路子，先保证推荐结果不空白，再随着数据丰富逐步切换到个性化推荐。

4. 系统架构与核心实现：前端、后端、算法模块怎么串起来

4.1 后端代码结构与企业级分层设计

整个后端的包结构是用分层架构来组织的，我习惯这样命名：controller层放接口入口，service层放业务逻辑，mapper层放数据库访问，model层放实体类，dto层放数据传输对象，common层放统一返回结果和异常处理。

com.clinic ├── controller # 接口层，接收前端请求 │ ├── PatientController.java │ ├── DoctorController.java │ ├── DrugController.java │ ├── RecommendController.java │ └── StatisticsController.java ├── service # 业务逻辑层 │ ├── patient │ ├── registration │ ├── prescription │ └── recommend ├── mapper # MyBatis接口层 │ ├── PatientMapper.java │ ├── PrescriptionItemMapper.java │ └── DrugMapper.java ├── model # 实体类 ├── dto # 请求/响应对象 ├── common # 统一返回体、全局异常处理 └── config # 配置类，如跨域、拦截器、Swagger

分层的好处很实际：controller层只做参数接收和结果返回，不会堆积业务代码，每个方法的逻辑都几百行的情况基本不会出现；service层可以单独做事务控制，比如处方开立时既要写入处方明细又要扣减药品库存，就必须保证在同一个事务里，一旦库存不足直接抛异常回滚；mapper层只做SQL和数据映射，方便后续单独优化慢查询。

统一返回体的设计也很关键。所有接口返回Result对象，包含code、message、data三个字段，前端根据code来判断成功还是失败。这样比直接返回JSON裸对象规范得多，出错了也能看到明确的消息提示。

4.2 核心接口设计与前端页面交互流程

系统核心的接口都是围绕业务对象设计的，一个对象一个Controller，接口路径尽量语义化。患者相关的就有新增患者、分页查询、查看详情、查看就诊历史等接口，药品相关的有药品字典分页、库存查询、入库出库操作等接口。推荐算法的接口单独放在RecommendController下，它不参与常规CRUD，而是负责触发算法计算和查询推荐结果。

前端的组件结构按照Vue项目的惯例组织。views目录下放页面级组件，比如PatientManage.vue、RegistrationView.vue、PrescriptionView.vue、DrugManage.vue、StatisticsView.vue、RecommendView.vue。每个页面组件内部会拆成多个子组件，比如药品管理页面就拆分成了药品表格子组件、入库弹窗子组件、库存预警子组件。

前后端交互用的是axios封装。我在utils/request.js里统一创建了axios实例，设置了baseURL（开发环境下通过Vue CLI的proxy代理到后端8080端口），然后在请求拦截器里把登录后拿到的token放进header，在响应拦截器里统一处理错误码，比如token过期就跳回登录页。这套封装逻辑一套下来，后面所有页面开发就不用重复处理登录认证的问题了。

4.3 协同过滤算法的完整代码实现

协同过滤的代码并不复杂，但一定要把数据预处理和核心计算分开写，这样便于调参和维护。我直接贴一段核心代码，展示药品推荐是怎么实现的。

@Service public class RecommendServiceImpl implements RecommendService { @Autowired private PrescriptionItemMapper prescriptionItemMapper; @Autowired private DrugMapper drugMapper; @Autowired private RecommendResultMapper recommendResultMapper; @Override public void generateRecommendation(Integer patientId) { // 1. 获取患者历史用药记录 List<UsageRecord> usageRecords = prescriptionItemMapper.selectUsageByPatient(patientId); if (CollectionUtils.isEmpty(usageRecords)) { recommendHotDrugs(patientId); // 冷启动兜底 return; } // 2. 构建患者已用药ID集合 Set<Integer> usedDrugIds = usageRecords.stream() .map(UsageRecord::getDrugId) .collect(Collectors.toSet()); // 3. 获取所有药品的相似度矩阵 List<DrugSimilarity> similarities = drugMapper.selectDrugSimilarity(); // 4. 累计候选药品得分 Map<Integer, Double> scoreMap = new HashMap<>(); for (UsageRecord usage : usageRecords) { for (DrugSimilarity similarity : similarities) { if (similarity.getDrugAId().equals(usage.getDrugId()) && !usedDrugIds.contains(similarity.getDrugBId())) { double weight = usage.getUsageCount() * 1.0; scoreMap.merge(similarity.getDrugBId(), similarity.getSimilarity() * weight, Double::sum); } } } // 5. 按得分排序取前10 List<Map.Entry<Integer, Double>> sorted = scoreMap.entrySet().stream() .sorted((e1, e2) -> Double.compare(e2.getValue(), e1.getValue())) .limit(10) .collect(Collectors.toList()); // 6. 先清后写，落库推荐结果 recommendResultMapper.deleteByPatientId(patientId); for (Map.Entry<Integer, Double> entry : sorted) { RecommendResult result = new RecommendResult(); result.setPatientId(patientId); result.setRecommendType(2); result.setTargetId(entry.getKey()); result.setScore(entry.getValue().doubleValue()); recommendResultMapper.insert(result); } } }

这段代码的算法过程很直白。第1步查历史用药，只要一条记录都没有就直接走热门推荐，不让输出空列表。第2步把已用药放进Set，这是防止推荐出去的东西是患者早就用过的。第3步获取所有相似度关系，把相似度矩阵一次性加载到内存里。第4步是核心的加权累计，把患者对每个历史药品的用量作为权重，乘以相似度，对候选药品进行加权汇总。第5步排序截断，第6步写入推荐结果表。

在真实业务中，如果药品上千种、患者上万，一次性加载全部相似度矩阵到内存可能不现实。这时候可以分治处理：只加载和目标患者历史用药相关的药品相似度记录，用SQL的IN条件过滤出局部相似度。我在项目里就是这么做的，推荐效果没有打折扣，内存占用反而下降了一个量级。

4.4 数据库初始化脚本与关键SQL实现

数据库脚本是整个项目能跑起来的基石。我建表用的是MySQL的InnoDB引擎，字符集统一utf8mb4，排序规则用utf8mb4_general_ci，这样才能稳定支持中文。外键我一般建表时不占位，而是在应用层来控制关联，这样后续做数据迁移和分库分表会灵活很多。

造一点核心建表SQL看设计：

CREATE TABLE `patient_info` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '主键', `patient_no` VARCHAR(32) DEFAULT NULL COMMENT '患者编号', `name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT DEFAULT NULL COMMENT '性别 1男 2女', `age` INT DEFAULT NULL COMMENT '年龄', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `allergy_history` VARCHAR(255) DEFAULT NULL COMMENT '过敏史', `member_level` TINYINT DEFAULT 0 COMMENT '会员等级', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='患者信息表'; CREATE TABLE `prescription_item` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '主键', `prescription_id` INT NOT NULL COMMENT '处方ID', `drug_id` INT NOT NULL COMMENT '药品ID', `quantity` INT DEFAULT 1 COMMENT '数量', `usage_instruction` VARCHAR(100) DEFAULT NULL COMMENT '用法用量', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_drug_id` (`drug_id`), KEY `idx_prescription_id` (`prescription_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='处方明细表';

这两张表是整个推荐算法的数据源头，特别是prescription_item，算法拿到patientId之后，会先通过关联prescription找到哪些药品是这个患者用过的。索引在query里能不能命中，直接影响算法执行速度。我踩过一个坑，一开始没在prescription_id上加索引，结果患者历史用药查询在大数据量下直接全表扫描，延迟飙升。加索引之后，时间立刻下去了。

药品协同过滤还需要一张专门存相似度的表，算法每次启动后自动更新：

CREATE TABLE `drug_similarity` ( `id` INT NOT NULL AUTO_INCREMENT, `drug_a_id` INT NOT NULL, `drug_b_id` INT NOT NULL, `similarity` DECIMAL(10, 6) DEFAULT NULL, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_drug_a` (`drug_a_id`), KEY `idx_drug_b` (`drug_b_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='药品相似度矩阵';

这张表的生成可以通过一条固定的SQL来完成。思路是：统计任意两个药品在同一个患者历史处方里共同出现的频次，再除以各自出现的总频次的平方根。写成SQL：

INSERT INTO drug_similarity (drug_a_id, drug_b_id, similarity) SELECT a.drug_id, b.drug_id, COUNT(DISTINCT a.prescription_id) / SQRT(cntA * cntB) AS similarity FROM prescription_item a JOIN prescription_item b ON a.prescription_id = b.prescription_id AND a.drug_id < b.drug_id JOIN (SELECT drug_id, COUNT(*) AS cnt FROM prescription_item GROUP BY drug_id) ta ON ta.drug_id = a.drug_id JOIN (SELECT drug_id, COUNT(*) AS cnt FROM prescription_item GROUP BY drug_id) tb ON tb.drug_id = b.drug_id GROUP BY a.drug_id, b.drug_id;

这条SQL能算出基础相似度，不过在数据量大时跑全表连接会很慢。实际项目里我会用定时任务来刷，凌晨执行一次，或者每天业务空闲时间执行一次，把结果同步到drug_similarity表里。这样在算法运行时有现成的相似度可用，不用实时聚合计算，性能会稳定很多。

5. 实操过程：从零初始化到完整跑通系统

5.1 环境准备与基础依赖安装

动手之前先把环境准备好，按我的项目经验，版本匹配是第一位的。后端用的是JDK 1.8，配SpringBoot 2.7.x；如果你非要用JDK 17也不是不行，但SpringBoot 2.x在JDK 17下可能要额外处理一些反射访问的权限问题，体验不如直接用1.8省心。

前端用Node.js 16.20.2 + npm 8.x，Vue CLI 5.x创建的Vue2项目。要注意的是nvm管理Node版本非常必要，千万不要只用一个系统自带的Node版本，很容易因为版本过新导致依赖编译失败。

MySQL用5.7或者8.0都行，我建议5.7，因为稳定、内存占用小，虚拟机上跑起来不卡。如果是全新的服务器，5.7也容易通过yum或者apt装好。

开发工具方面，后端IDE用IDEA，配置好Lombok插件，否则实体类的getter/setter编译会报错。前端用VS Code，装好Vetur或者Volar插件。数据库管理工具用Navicat或者DataGrip都可以，我个人更推荐DataGrip，对MySQL和SQL脚本兼容性都很好。

5.2 第一步：建库并初始化数据

数据库初始化是整个项目最容易出问题的一步，因为我一开始用的MySQL默认字符集是latin1，导入脚本之后所有中文都变成了问号，排查了非常久。现在我的习惯是建库时直接指定utf8mb4，避免后面所有表都要手动改。

CREATE DATABASE IF NOT EXISTS clinic_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE clinic_db;

然后按顺序执行项目附带的sql脚本，先建表再插入初始化数据。脚本文件在完整项目源码的sql目录下，一般叫做clinic_db.sql，里面有全部建表语句和管理员账号数据。导入之后检查一下关键表有没有数据，比如sys_user表要有一条admin账号，药品字典表要有几十条基础药品记录，不然前端页面上全是空白，后面联调都不方便。

初始化数据这一步千万别偷懒。如果药品表是空的，即便后端能启动，推荐算法也没法演示效果。我一般会往库里插入100个虚拟患者、50个医生、500条历史处方记录，这样算法在第一次跑的时候就能算出一个像样的推荐结果，页面展示出来才有说服力。

5.3 第二步：修改配置并启动SpringBoot后端

后端项目的配置文件在src/main/resources/application.yml，最重要的就是数据源配置。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/clinic_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.clinic.model configuration: map-underscore-to-camel-case: true

url里面加上useUnicode=true和characterEncoding=utf8mb4，这一项至关重要。我之前漏掉以后，前端提交的中文到后端全都乱码，后来加上就好了。map-underscore-to-camel-case设为true之后，数据库里下划线字段名就能自动映射成Java驼峰属性，不用每个字段都写@TableField注解，代码能少写很多。

然后直接启动Application主类，看到Spring Boot启动成功的日志输出，并且没有端口冲突，就算后端就绪了。我习惯用IDEA的Run窗口跑，因为报错信息可以直接跳转到具体代码行，排查问题非常方便。

5.4 第三步：安装依赖并启动Vue前端

前端项目结构一般是标准Vue CLI生成的样子，package.json在根目录。

cd clinic-frontend npm install npm run serve

npm install这一步我踩过很多次坑，最典型的就是依赖和Node版本不匹配导致node-sass编译报错。解决办法是换用sass而不是node-sass，或者干脆用npm的镜像源来安装依赖。如果npm install时网络很慢，建议把registry配成国内镜像源，下载速度会快很多。

启动成功之后，访问http://localhost:8081，能看到一个登录页面。默认账号是admin，密码是123456。输入进去之后跳转到系统首页，整个页面的布局是标准的后台管理样式。这一套流程走通了，说明前后端的基础联调已经没问题了。

5.5 第四步：跨域配置与接口联调

前后端分离必然会遇到跨域问题。如果前端用8081端口访问后端8080端口，浏览器默认会拦截跨域请求。解决方式有两种：一种是在后端加全局CORS配置，另一种是在前端通过Vue CLI的proxy代理转发，让浏览器认为请求是同源的。

我推荐项目里用前端proxy的方式，因为生产环境部署时可以直接用Nginx做反向代理，开发的时候也用proxy，环境切换只需要改一个变量。在vue.config.js中配置：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

这样前端发起的/api/login请求会被代理到后端的8080端口，不会出现跨域报错。注意后端接口的requestMapping如果写成/api/login，那就刚好匹配。如果后端没加/api前缀，那就需要在proxy里把路径重写一下，用pathRewrite去掉/api。很多新手在这里对不上，就会一直报404。

5.6 第五步：演示推荐算法，准备测试数据

系统跑通以后，重点要演示推荐算法的效果。我建议按照这个步骤准备测试数据。

第一步，手工在系统里创建几个测试患者，登记真实的年龄、症状描述、过敏史。第二步，给这些患者分别开几份处方，每次就诊开2到3种药品。第三步，在患者之间提前预设一些用药重叠，比如A患者和B患者都开过维生素C和感冒灵，但B患者额外开过一款止咳糖浆，这样A患者的推荐列表里就应该出现止咳糖浆，演示效果就很直观。

然后在医生端打开患者的就诊页面，点击“获取推荐”按钮，系统会调用后端算法接口，在页面上展示推荐药品列表。这一步跑通，整个项目的核心亮点就全部验收完成了。

6. 常见问题与排查技巧实录

6.1 数据库连接报错：Access denied和时区问题

MySQL数据库连接是新手最容易栽的地方。第一种报错是Access denied for user 'root'@'localhost'，这是密码错误或者用户权限问题。排查思路很简单：先在命令行用mysql -u root -p测试能否连上，如果命令行都连不上就说明密码或账号确实有问题，需要重置；如果命令行能连上但程序报错，就去确认application.yml里的配置是不是和真实环境一致。

第二种报错是The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，这是MySQL连接串里的serverTimezone没设置对。解决办法就是在JDBC连接串末尾加上serverTimezone=Asia/Shanghai，尤其是MySQL 8.0版本必须明确指定时区，否则会直接拒绝连接。

6.2 SpringBoot启动失败：端口占用和依赖冲突

启动后端时如果看到Port 8080 was already in use，说明8080端口已经被其他进程占用了。Windows下用netstat -ano | findstr 8080找到占用进程的PID，然后去任务管理器结束对应进程；或者在application.yml里把server.port改成8081，避开冲突。我觉得改端口更省事，但要记得把前端proxy的target端口也同步改掉。

如果报的是依赖冲突，比如BeanDefinitionStoreException，多半是Maven依赖里引入了不同版本的包，或者某个依赖没有下载完整。在IDEA里执行mvn clean install重新拉取一遍依赖，基本能解决。还有一次遇到的是Lombok和JDK版本不兼容，升级Lombok插件版本就好了。

6.3 前端接口请求404：代理前缀与后端映射不对齐

前端成功启动后，登录请求一直报404，这种情况十有八九是proxy的path和spring的requestMapping对不上。比如proxy配置的是/api，但后端Controller的路径是/patient/list没有/api前缀，两者匹配不上，请求就404了。

解决方法有两个方向：要么给后端所有Controller统一加上/api前缀，要么去掉proxy里的/api并且转发时不重写路径。我当时的项目是统一加前缀的方案，在Controller类的@RequestMapping上写/api。这样所有接口都带/api，前端请求也能正确代理，后面就不会再出现404了。

6.4 推荐结果为空：数据稀疏和算法边界问题

协同过滤推荐结果为空，是最容易让人懵的一个问题。排查逻辑按三步走。

第一步先看患者有没有历史用药记录。如果这个患者是新建的，一条处方都没有，算法一进来就会判断usageRecords为空，直接走热门推荐兜底。如果连热门推荐都没有数据，那就意味着处方明细表完全没数据，或者药品字典表是空的，这种情况只能先去录入基础数据。

第二步再看药品相似度表drug_similarity是否有记录。如果算法能从相似度表里拿到数据但算出来的score都是0，大概率是weight处理有问题，比如usageCount取出来是null，乘到分数上就变成0了。在代码里对空值做防御性处理很重要，尤其是从数据库查出的统计字段，很可能为null。

第三步看推荐结果表是否被写入。如果recommend_result表里有记录但前端页面没显示，那要去查前端页面查询时是不是按patient_id来过滤的，以及RecommendResult里的recommendType字段是否正确。推荐类型1是医生，2是药品，如果前端默认只查类型1但算法写的是类型2，页面当然空白。

6.5 中文乱码的集中排查与根治

中文乱码问题的根因通常是三层中某一层的字符集配置不对。第一层是数据库，建库时用utf8mb4，连接串带characterEncoding=utf8mb4。第二层是后端响应，SpringBoot的Jackson配置需要指定UTF-8编码，在application.yml里加http编码过滤器配置。第三层是前端存储，表单提交时Vue默认会用UTF-8编码，只要后端能正确解码，就不会出问题。

我整理了一个快速排查顺序：先看数据库表字段的collation是不是utf8mb4_general_ci，再看后端日志里接收到的参数中文正不正常，最后检查前端页面meta里有没有charset=utf-8。这三个位置只要都是UTF-8，中文基本不会乱。

6.6 常见问题排查速查表

这套速查表是我在实际搭项目过程中总结出来的，不能说覆盖所有问题，但覆盖了绝大多数新手会踩的坑。把这些坑提前排掉，项目从启动到跑通联调，基本半天就能搞定。

7. 部署扩展与我的实操体会

最后聊几句部署上线和扩展方向。项目真正上线时不能用开发模式的npm run serve，前端代码要用npm run build构建成静态文件，让Nginx托管；后端打包成JAR用java -jar运行。Nginx再配置反向代理，把/api请求转发到后端的8080端口，这样就形成了一套标准的前后端分离部署架构。

数据库方面，上线前一定要做备份策略。MySQL可以用mysqldump定时备份，每天凌晨跑一次，备份文件保留七天以上。诊所有限的IT环境下不能指望人工记住天天备份，自动化脚本才是可靠保障。

我个人在整个开发过程中体会最深的是：协同过滤算法不是灵丹妙药，它的效果完全取决于数据质量和表结构设计。同样的算法，数据表设计合理效果立竿见影，数据表里字段混乱、关系不清晰，跑出来的结果就是一堆垃圾。所以在动手写算法之前，一定先把患者、病历、处方、药品这四张核心表的关系梳理清楚。

还有一个建议是别把推荐结果直接推给患者签字确认或者当成诊断依据，它更适合做辅助提示，比如在医生开药时旁边加一栏“相似患者常用药物”，让医生自己判断是否采纳。这样既利用了算法数据挖掘的价值，又尊重医疗场景中专业判断的主体地位。

这套系统后续可以扩展的方向也很多。比如加上时间衰减因子，让越近期的行为权重越高；再比如把相似患者的病历摘要拿来做解释，告诉医生“因为有某某相似患者用过这款药，所以系统才推荐”。这些都是低成本高收益的算法增强手段。

做完整套系统再回头看，SpringBoot+Vue+MyBatis+MySQL这组经典技术栈，配上协同过滤算法，用在私人诊所管理场景里非常顺手。项目代码结构清晰，业务闭环完整，算法有实际业务落地点，不会让人觉得是为了凑技术点硬塞的功能。如果你正好在找一套能讲清楚业务和技术双重亮点的完整项目，这份源码值得花时间拆开读一遍。