企业官网建设流程全解析

毕业设计推荐：AI智慧社区综合健康管理系统(AI智能健康问答、WebSocket在线咨询、ECharts数据可视化、健康指标监测、居民健康档案、健康评估报告、健康知识与社区活动)（SpringBoot+Vue3+uni-app+deepseek(用户/医生小程序，用户门户，医生工作站，后台管理系统) 四端完整版）

写给正在愁毕设选题的计算机专业同学。本文介绍一个已完成的智慧社区综合健康管理系统，覆盖居民门户、医生工作站、管理后台、微信小程序四端，技术栈主流、业务闭环完整、有现成截图和论文素材，适合作为毕业设计基础进行二次开发。

一、为什么推荐这个选题？

很多同学选毕设时的困境：

• 题目太大：做一个"医疗平台"，结果只做了个登录加挂号，答辩被问穿。
• 题目太小：做一个"学生信息管理系统"，功能单薄，查重率高，老师不感兴趣。
• 没有亮点：CRUD 谁都会写，答辩时说不出一个"技术难点"。
• 业务脱节：做出来的东西一看就是网上扒的模板，自己都不信能用。

智慧社区健康管理系统恰好卡在一个合适的位置：

二、这个系统解决什么问题？

先说清楚业务，答辩才讲得动人。

社区卫生服务中心是我国分级诊疗体系的"网底"，承担着居民健康档案管理、慢病随访、常见病诊疗等职能。但现实中痛点很明显：

系统的解法是：以「就诊记录」为统一主轴，把健康档案、指标监测、预约挂号、在线咨询、病历书写、处方开具、就诊评价全部串联，形成"建档—监测—就医—诊疗—评价"的完整闭环。

同时，给不同角色配不同终端——居民要轻便，医生要高效，管理员要全局可视。这四端恰好构成一句答辩时可以重点讲的架构表述：四端一核。

三、技术栈一览

主流、成熟、网上资料多，遇到问题好搜。

代码规模参考：后端 81 个 Java 文件，四个前端合计 89 个 Vue/JS 文件，量足够撑起一份毕设。

关于端口多：开发期四端分开跑是为了热更新。实际部署只暴露一个端口（80/443），由 Nginx 按路径把/、/doctor、/admin、/api分发到各端，四端工程并不构成额外运维负担。这一点答辩时如果被问到，可以直接答。

四、系统架构：四端一核

┌──────────┬──────────────┬──────────┬──────────────┐ │ 居民门户 │ 医生工作站 │ 管理后台 │ 移动端小程序 │ │ :5174 │ :5176 │ :5175 │ :5181 │ └────┬─────┴──────┬───────┴────┬─────┴──────┬───────┘ └────────────┴────────────┴────────────┘ 统一 REST API · JWT 鉴权 ┌────────────────────────────────────────────────────┐ │ SpringBoot 业务核心层 │ │ 接诊即授权 · 号源并发 · 库存扣减 · 实时通信 · AI │ └────────────────────────────────────────────────────┘ │ MyBatis-Plus → MySQL 8.4（25 表） │ DeepSeek 大模型 ← 本地知识库降级兜底

4.1 数据库设计思路（25 张表，五大业务域）

设计的巧思在于t_visit（就诊记录）作为统一模型：无论居民是通过预约门诊、在线咨询还是线下就诊，最终都写入同一张表，用source字段区分来源。这一设计解决了传统系统中"健康档案"和"诊疗记录"两张皮的问题，也是整个系统能形成闭环的关键。

写论文时，这个"统一模型"的思路很值得单独讲一节——它体现的是建模能力，不是 CRUD 能力。

五、六个可以深挖的技术亮点

这一节是答辩的核心弹药。每个点都足够讲 2-3 分钟，六个加起来轻松撑满 15 分钟。

5.1 接诊即授权：医疗数据的权限模型设计

问题：医疗数据高度敏感，但医生接诊时又必须看到完整既往史。要么"全可见"侵犯隐私，要么"一律不可见"妨碍诊疗。

方案：以业务行为自动产生数据授权关系——

医生对某居民有病历访问权 ⟺ 存在接诊记录 或 咨询会话记录

publicbooleancanAccess(LongdoctorId,LongresidentId){if(UserContext.isAdmin())returntrue;// 管理员监管可见longvisitCnt=visitMapper.selectCount(newLambdaQueryWrapper<Visit>().eq(Visit::getDoctorId,doctorId).eq(Visit::getResidentId,residentId));if(visitCnt>0)returntrue;longconsultCnt=consultMapper.selectCount(newLambdaQueryWrapper<ConsultSession>().eq(ConsultSession::getDoctorId,doctorId).eq(ConsultSession::getResidentId,residentId));returnconsultCnt>0;}

三个讲得出的好处：

• 授权自动产生：居民主动找某医生看病，就等于完成了一次授权，不需要额外点"允许查看"
• 跨医生连续诊疗：这次找 B 医生，B 能看到 A 医生之前写的全部病历，避免重复检查和用药冲突
• 隐私边界清晰：医生在列表里翻不到从没接诊过的居民的病历

答辩话术：这不是简单的"权限校验"，而是一个基于业务关系的动态权限模型。它比 RBAC 更贴近医疗场景，是设计中真正有思考的部分。

5.2 号源与库存的并发控制（面试高频考点）

问题：两个医生同时给不同患者开同一种药，如果写"先查库存再扣减"，两者都查到 100 盒够，各自扣减后就出错了。号源超挂同理。

方案：把"资源是否充足"的判断下推到数据库，与扣减合并为一条原子 SQL，用受影响行数判定结果。

// 库存扣减：条件更新防负库存introws=drugMapper.update(null,newLambdaUpdateWrapper<Drug>().eq(Drug::getId,drugId).apply("stock >= {0}",qty)// 关键：SQL 层条件.setSql("stock = stock - "+qty));if(rows==0){thrownewBusinessException(drug.getName()+" 库存不足，请刷新后重试");}

生成的 SQL：

UPDATEt_drugSETstock=stock-3WHEREid=?ANDstock>=3

号源扣减同理：UPDATE t_schedule SET booked = booked + 1 WHERE id = ? AND booked < quota

为什么这个方案好：

• 不用引入分布式锁：单机条件更新就够，没有额外组件依赖、没有锁开销
• 判据可靠：用"受影响行数"比"查了再判"可靠得多，因为判断和写入是原子的
• 可追溯：扣减成功后立即写库存流水（变动前后值 + 关联处方号）

答辩话术：这是典型的"乐观并发控制"，本质是把并发控制交给数据库的行锁，应用层只负责判读结果。相比悲观锁性能更好，相比分布式锁实现更轻。

5.3 【重点】在线咨询：STOMP 实时消息

这是系统里技术含量最高的模块之一，也是答辩最容易出彩的地方。

完整链路：

居民发起咨询 → STOMP 握手(CONNECT 帧带 JWT) → 订阅 /user/queue/msg ↓ 发送消息 → ① 先落库 t_consult_message → ② 再 convertAndSendToUser 推送 ↓ 对方在线：秒级收到 ｜ 对方离线：重新进入时靠 afterId 增量拉取 ↓ 结束咨询 → 自动生成就诊记录（t_visit, source=2）

核心代码：为什么必须"先落库再推送"

@TransactionalpublicConsultMessagesend(LongsessionId,LongsenderUserId,StringsenderRole,Stringcontent,Stringtype){// ① 先落库（关键！）ConsultMessagemsg=newConsultMessage();msg.setSessionId(sessionId);msg.setSenderRole(senderRole);msg.setContent(content);messageMapper.insert(msg);// 更新会话最后消息与未读数if("RESIDENT".equals(senderRole)){s.setDoctorUnread(s.getDoctorUnread()+1);}else{s.setResidentUnread(s.getResidentUnread()+1);}sessionMapper.updateById(s);// ② 再推送（关键！）messagingTemplate.convertAndSendToUser(String.valueOf(peerUserId),"/queue/msg",payload(msg,sessionId));returnmsg;}

为什么不能反过来？如果先推送再落库，接收方离线时消息就直接丢了，没有任何补偿手段。而先落库后推送，即使对方当前离线，重新进入会话时用?afterId=就能拉全历史。这是 IM 系统的标准做法。

STOMP 相比裸 WebSocket 的优势：提供了发布订阅语义，服务端能按用户维度精准推送（/user/queue/msg），不用自己维护"哪个连接属于哪个用户"的路由表。

@Configuration@EnableWebSocketMessageBrokerpublicclassWebSocketConfigimplementsWebSocketMessageBrokerConfigurer{@OverridepublicvoidconfigureMessageBroker(MessageBrokerRegistryregistry){registry.enableSimpleBroker("/topic","/queue");// 订阅前缀registry.setApplicationDestinationPrefixes("/app");// 发送前缀registry.setUserDestinationPrefix("/user");// 点对点推送}@OverridepublicvoidregisterStompEndpoints(StompEndpointRegistryregistry){registry.addEndpoint("/ws/chat").setAllowedOriginPatterns("*").withSockJS();}}

未读数的两个细节：

• 按角色分别累加：会话表有resident_unread和doctor_unread两个字段，谁发的就加对方那边的
• 进入会话即清零：只清自己这一侧，同时把对方发的消息标为已读

额外亮点：结束咨询后自动生成就诊记录，诊断写"在线咨询（未面诊）"，主诉取居民第一条消息，处理意见汇总医生回复。这样线上咨询也能沉淀为结构化病历，打通了线上线下两条链路。并且做了幂等保护，重复结束不会产生多条记录。

答辩话术：这一块能讲的东西非常多——为什么用 STOMP 而不是轮询、为什么先落库、未读数怎么设计、离线消息怎么补偿、幂等怎么保证。老师随便挑一个问都能答上来。

5.4 【重点】AI 健康问答：SSE 流式 + 业务注入 + 本地降级

AI 模块的难点不在"调通接口"，而在让它有针对性、且不怕断网。

第一层：SSE 流式输出

后端用SseEmitter推送三类命名事件，前端逐块追加渲染，形成打字机效果：

publicSseEmitterchat(Stringmessage){SseEmitteremitter=newSseEmitter(90_000L);newThread(()->{try{deepSeekClient.stream(buildPrompt(uid),message,delta->{answer.append(delta);safeSend(emitter,"message",delta);// 逐 token 推送});safeSend(emitter,"done","[DONE]");}catch(Exceptione){safeSend(emitter,"error","AI 服务暂时不可用");}finally{emitter.complete();}},"ai-sse").start();returnemitter;}

第二层：业务数据注入（这是最有价值的一点）

提示词里把居民的健康档案拼进去，让回答结合具体病情，而不是泛泛而谈：

privateStringbuildPrompt(Longuid){StringBuildersb=newStringBuilder("你是「智慧社区健康管理系统」的资深健康顾问，擅长慢性病管理、营养、运动与老年保健。\n");Residentr=residentMapper.selectOne(...);if(r!=null){sb.append("当前居民健康档案：\n");sb.append("- 既往病史：").append(r.getPastHistory()).append("\n");sb.append("- 过敏史：").append(r.getAllergy()).append("（回答时务必规避相关药物）\n");sb.append("- 最近健康指标：血压 132/84；血糖 6.8（异常）\n");}returnsb.toString();}

第三层：本地降级（演示不依赖网络）

没配 API Key 或调用失败时，自动切换本地健康知识库，覆盖血压、血糖、心率、体重、饮食、运动、睡眠、过敏、老年人保健等10 个主题，每个主题 5-6 条可操作建议，同样以流式分片输出。

privatevoidstreamLocal(Stringquestion,StringBuilderanswer,SseEmitteremitter){Stringcontent=localAnswer(question);inti=0;while(i<content.length()){intstep=2+newRandom().nextInt(3);// 模拟流式：每次 2-4 字符intend=Math.min(content.length(),i+step);Stringseg=content.substring(i,end);answer.append(seg);safeSend(emitter,"message",seg);Thread.sleep(28);i=end;}}

这个设计很关键：答辩时如果外网不通、Key 欠费，AI 功能依然流畅演示，用户完全感觉不到差异。

实测数据：单次回答分 85-103 个片段，首字节 450ms，10 个主题命中准确。

5.5 健康指标异常自动判定

把医学阈值抽成规则表，代码里不写死，改阈值不用改代码：

CREATETABLEt_metric_rule(metric_typeVARCHAR(20),-- BP / GLU / HR / WEIGHTfield_nameVARCHAR(30),-- systolic / diastolic / glucose / heart_rate / weightmin_normalDECIMAL(8,2),max_normalDECIMAL(8,2),unitVARCHAR(20),abnormal_tipVARCHAR(200));

判定时逐字段比对，命中就拼接中文说明：

for(MetricRulerule:rules){BigDecimalv=按 field_name 取出值;booleanlow=v.compareTo(rule.getMinNormal())<0;booleanhigh=v.compareTo(rule.getMaxNormal())>0;if(low||high)tips.add(label+(low?"偏低":"偏高")+"："+v+rule.getUnit());}if(!tips.isEmpty()){m.setIsAbnormal(1);m.setAbnormalDesc(String.join("；",tips));}

实测：输入 155/98 会自动生成“舒张压偏高：98mmHg；收缩压偏高：155mmHg”。

答辩话术：这是"配置化设计"的典型应用，体现了把业务规则从代码中解耦的工程思想。

5.6 数据可视化（ECharts）

四端都有图表，工作量饱满且效果直观：

• 居民端 / 医生端：血压双线趋势图（收缩压/舒张压不同颜色）、血糖/心率/体重单指标趋势，支持 7/30/90 天切换
• 管理端：近 7 日预约与就诊趋势折线图、健康标签分布饼图、科室就诊量柱状图
• 评价词云：用 HanLP 对评价文本分词聚合，取 Top 80 渲染词云

HanLP 分词这一块也是个不错的加分项——中文没有天然词边界，必须分词才能统计词频。

六、界面展示

四端页面，随便挑几个感受一下。

6.1 居民门户（PC 端）

首页采用"轮播 + 公告 + 健康概览 + 快捷入口"布局，图片全部使用真实医疗健康场景素材。

健康档案页，病史与过敏记录以红色左边框突出显示，方便医生快速识别用药禁忌。

健康数据页，血压双线趋势图，异常数据在表格中红色高亮。

6.2 医生工作站（PC 端）

这是本系统的一个差异化亮点——医生端单独做了 PC 端，因为诊室里需要大屏看趋势、键盘敲病历、并排核对库存。

书写病历页：左侧表单 + 右侧常驻参考（过敏史红框警示、长期用药、最近指标、历史病历时间线可展开、一键带入上次病历）。

开具处方页：左药品库 + 右处方单双栏布局，选药即时校验库存，开方自动扣减。

6.3 管理后台

数据看板：八项指标 + 趋势 + 分布 + 词云，全部 ECharts 绘制。

药品库存管理，支持入库、预警、流水查询。

6.4 移动端小程序（双角色）

一套代码同时承载居民端（15 页）与医生端（6 页），登录后按 role 分流。

医生端工作台明确移动定位，专业诊疗引导至 PC 端。

6.5 AI 问答与在线咨询

七、踩过的坑（帮同学避雷）

这些都是真实遇到并解决的，你可以少走弯路。

坑 1：小程序页面根节点用自定义类名会丢全局样式

uni-app 里App.vue定义的.page、.card、.btn这些全局类只对同名类生效。页面根节点写成consult-page就全丢了，样式全无，排查半天才发现。

解法：关键样式在各页 scoped 里补齐，或者根节点统一用class="page"。

坑 2：医生角色调管理员接口导致 403

开处方页需要药品列表，图省事直接用了/api/admin/drug/list，结果医生角色被 JWT 拦截器拦了。

解法：加医生专属只读接口/api/doctor/drug/list，只返回在售药品。

教训：多角色系统里，接口路径和角色权限必须严格对应，不能复用。

坑 3：流式输出会切断关键词，测试断言会误判

做自动化测试时断言"回答里应包含’本地健康知识库’"，结果一直 FAIL。排查发现——不是功能问题，是流式把关键词切碎了：

event:message data:（当前为 event:message data:本地健康 event:message data:知识 event:message data:库模

解法：先拼接所有 data 片段再断言。

坑 4：Maven 增量构建没复制静态资源

替换了图片后重新package，但target/classes里还是旧图，接口返回的还是老图片。

解法：必须mvn clean package，或者手动删target/classes/static。

坑 5：页面只有第 1 条数据（数组取 [0] 的老毛病）

小程序咨询页只能看到第一个居民的对话。查代码发现是拿数组直接取第一条自动进入，页面上根本没有渲染列表。

解法：改成"列表 → 聊天"两级视图。

教训：涉及多条目数据的地方，一定要检查 UI 上是否真的渲染了列表。

坑 6：前端分页代码被批量脚本插到了变量声明之前

批量修改代码时锚点选错，报Cannot access 'list' before initialization。

教训：批量改代码后必须跑一遍验证，不能只看文件生成成功。

八、毕设答辩经验

8.1 答辩 PPT 建议结构（18 页左右）

本系统配套的 PPT 是 18 页，结构可以直接参考：

建议：第 9、10 两页（实时消息、AI 问答）多花时间打磨，这两页最容易出彩。

8.2 老师常问的问题 & 参考答案

Q1：为什么做四个端？是不是功能重复？

不是重复，是场景不同。居民需要轻便的记录工具，所以门户+小程序就够了；医生在诊室里需要大屏看趋势、键盘敲病历、并排核对药品库存，这些在手机上效率极低，所以做了 PC 工作站；医生在诊室外只需要回复咨询和看患者速览，所以小程序保留这三项。端的设计依据是工作场景，不是技术堆砌。

Q2：你的并发控制怎么做的？为什么不用分布式锁？

号源和库存都用数据库条件更新，把判断和扣减合并成一条原子 SQL，用受影响行数判定。比如UPDATE t_drug SET stock = stock - 3 WHERE id = ? AND stock >= 3。如果返回 0 行就是库存不足。这样并发下只有一个能成功。不用分布式锁是因为单机条件更新就能保证强一致，而且没有额外组件依赖、没有锁开销，对社区级系统是最优解。

Q3：AI 回答不准怎么办？如果 API 挂了怎么办？

两个层面。准确性上，我把居民的健康档案（病史、过敏、用药、最近指标）注入提示词，让回答结合具体病情，而不是泛泛而谈。可用性上，做了本地知识库降级——没配 Key 或调用失败时自动切换，覆盖 10 个健康主题，同样以流式输出。这样答辩演示完全不依赖网络。

Q4：为什么消息要"先落库再推送"？

如果先推送，接收方离线时消息就丢了，没有补偿手段。先落库再推送，即使对方离线，重新进入会话时用 afterId 增量拉取就能补齐。这是 IM 系统的标准做法。

Q5：你说的"接诊即授权"具体怎么实现？

判断医生对该居民是否有接诊记录或咨询会话记录，有就允许查看完整病历，没有就只能看基本信息。这样既满足隐私要求，又保证医生接诊时能看到完整既往史。而且授权是由业务行为自动产生的，不需要居民手动点授权，符合医疗场景习惯。

Q6：项目有什么不足？

说实话有几个方向：一是没接真实支付，处方只记录金额；二是随访功能只做了基础记录，没实现自动随访计划；三是 AI 没用 RAG 检索增强，还存在幻觉风险；四是小程序没在微信真机做适配验证；五是还没建运维监控体系。这些都在论文第7章写了，也是后续要补的。

提示：主动承认不足比被问出来好。老师更看重你是否清楚边界。

8.3 答辩前一天 checklist

• 五个服务全部能启动（后端 + 四端），端口不冲突
• 数据库导入正常，种子数据完整
• 演示账号能登录（admin / doctor / resident）
• AI 功能测试一遍（确认本地降级生效）
• 实时咨询测试一遍（开两个浏览器，一个居民一个医生）
• 演示主流程跑通：居民预约 → 医生接诊 → 写病历 → 开处方 → 居民评价
• PPT 拷贝到 U 盘 + 云端各一份
• 论文打印版装订好
• 提前 10 分钟到教室测试投影

九、这个系统适合你吗？

适合你，如果：

• 选题方向是 Web 开发 / 信息系统 / 软件工程
• 想要一个业务完整、有真实场景的毕设基础
• 需要多端覆盖（PC + 小程序）来充实工作量
• 希望答辩时有 6 个可以深挖的技术点
• 想贴合政策热点（健康中国、分级诊疗）提升选题立意
• 打算在源码基础上加自己的功能（比如接入真实支付、加 RAG、做智能分诊）

十、配套材料

这个系统目前已经产出的配套材料：

—

十一、写在最后

毕设选题的核心原则：不要选最大的，要选能做完的。

一个能完整跑通、有真实业务场景、答辩能讲清楚技术难点的系统，远比一个宏大但只有半成品的"XX 平台"更能拿高分。

智慧社区健康管理系统提供了这样一个起点：

• 业务闭环完整：建档 → 监测 → 就医 → 诊疗 → 评价
• 技术亮点明确：接诊即授权、条件更新并发控制、STOMP 实时消息、SSE 流式 AI
• 端侧覆盖饱满：居民门户 + 医生工作站 + 管理后台 + 小程序，四端一核
• 场景真实可信：贴合社区卫生服务实际，不是编的需求
• 有 AI 热点：DeepSeek 集成 + 提示词工程 + 降级兜底，能讲出深度

在源码基础上加一点自己的思考和改进，就是一个拿得出手的毕业设计。

如果这篇文章对你有帮助，欢迎点赞收藏。有关于毕设选题、四端架构、实时通信或 AI 接入的问题，评论区见。