VUE社区健康服务平台开发全流程：从需求拆解到部署实现

基于VUE的社区健康服务平台需要什么从需求拆解到落地实现这两年社区健康服务是个很实在的方向无论是社区卫生站的信息化改造还是居民健康档案的数字化管理大家都有一个共识缺一个轻量、好用、能快速上手的服务平台。于是我用VUE和相关生态做了一套社区健康服务平台说实话越做到后面越觉得这类系统真正的难点不是技术选型而是把业务需求想清楚、把交互细节打磨好。这篇文章就从头梳理一遍我的完整实现思路包括环境搭建、模块划分、权限体系、数据可视化、前后端联调以及部署上线希望能给正在做SpringBoot、VUE相关方向设计的朋友们一些参考。这套平台本身做的事情并不复杂面向社区居民提供健康档案查看与维护、健康资讯浏览、体检报告解读、社区医生服务预约以及管理员侧的基础信息管理、公告发布、数据统计等功能。但正因为业务范围广、用户角色多所以对于刚接触前后端分离开发模式的同学来说它是一个很合适的练手项目——麻雀虽小五脏俱全几乎涵盖了VUE项目开发中所有常用知识点。如果你正准备动手做类似的项目或者已经在开发过程中卡住了这篇文章会从为什么要这样设计的角度把关键的技术决策和踩坑经验都讲清楚。1. 项目启动前的需求和边界梳理每次接到新的项目我都会强迫自己先做一件事搞清楚这个系统到底要为谁服务、解决什么问题而不是一开始就埋头写代码。这一轮系统做下来我对需求分析这件事的体会又深了一层。1.1 这个平台的核心服务对象是谁社区健康服务平台从名字就能看出来核心场景在社区二字。它不同于大型医院的信息系统不需要支撑海量并发挂号也不涉及过于复杂的HIS业务流转它的价值在于把社区范围内的居民健康管理起来让数据能够流转起来。我参考了几个实际项目的做法最后把用户角色定为三类社区居民用户这是系统的最终服务对象。他们关心的是能不能查自己的健康档案、看体检报告、约社区医生的号、读一些健康科普文章。社区医生/健康管理员他们需要处理居民的预约申请维护居民的健康档案发布健康宣教内容并回复居民的咨询留言。系统管理员负责基础数据的维护比如用户管理、角色权限分配、公告发布、数据统计等。这种三角色模型比较经典也比较好实现权限控制。对于毕业设计来说也是比较稳妥的角色划分方式不需要做得过重但又能体现出RBAC权限管理的技术点。1.2 功能边界哪些做、哪些不做心里要有数项目最容易失控的地方就是需求蔓延。一开始我也想着要不要加在线问诊、电子处方、医保对接这些功能后来冷静一想如果你不是去大厂实习而是自己做毕设一个月内把这些全做完基本不现实而且会让系统变得臃肿难用。最终敲定的核心功能包括用户注册登录与个人信息维护健康档案的查看与维护体检记录的管理与报告上传健康资讯与科普文章的展示医生服务在线预约与后台受理社区公告发布与浏览留言反馈功能数据统计看板这里有一个重要的取舍逻辑凡是需要线下真实业务闭环才能做好的功能尽量简化凡是可以通过数据流转充分展示技术能力的功能尽量做深。比如在线问诊如果要做就要考虑音视频、排队、处方流转等等这些内容在毕设阶段很难有真正的医疗场景去落地而健康档案管理就不一样它就是标准的增删改查加上字段校验和权限过滤能很好地展现后端设计能力和前端页面编辑能力。1.3 业务流程图里最容易忽视的异常分支很多同学画流程图只画正常路径比如用户提交预约、医生同意、用户查看结果。但在实际开发中真正花时间的往往是那些异常分支居民重复提交同一时段预约系统该怎么办医生拒绝预约后居民端是否能看到原因说明管理员删除一个已有健康档案的用户关联数据怎么处理体检报告上传了错误文件类型前端如何校验、后端如何兜底这些在数据库表设计阶段就要考虑清楚否则后面写业务代码的时候会非常痛苦。我在设计预约表时就提前预留了status字段的多种状态值空间包括待确认、已通过、已拒绝、已取消、已完成、已过期这样后期扩展状态流转的时候就不需要频繁改表结构了。2. 从零搭建VUE项目技术栈选型与工程化配置技术选型决定了你后面开发顺不顺。我见过太多人一上来就跟着视频教程选了一堆花里胡哨的依赖包结果项目跑起来依赖冲突不断。这个项目我最终使用的是非常稳妥的一套组合。2.1 为什么最终选了VUE 2 Element UI而不是VUE 3我知道现在VUE 3已经很成熟了Composition API写起来也很爽但做这个项目的时候我最后还是选了VUE 2。原因很现实生态兼容性很多后端同学熟悉的管理后台模板、可视化组件库、上传组件在VUE 2生态里踩坑案例多、解决方案齐全。团队协作成本如果借用了网上很流畅的项目脚手架或者模板VUE 2版本占的比例仍然非常高二次修改时不会因为API差异卡住。毕业设计的答辩友好度老师重点关注的往往是你的业务逻辑是否跑通、代码结构是否清晰、关键难点是怎么解决的而不是你非要用最前沿的框架。当然如果你从一开始就是用VUE 3开发且已经很熟练那完全不用切换。这里不是推荐大家守旧而是要明白选什么技术栈取决于你当前阶段最需要的是什么。2.2 项目脚手架Vue CLI的初始化与实践我是用Vue CLI初始化项目的整体的步骤很简单vue create community-health在选择预设的时候我勾选了以下内容BabelRouterVuexCSS预处理器选择了SCSSLinter / Formatter选择了 ESLint Prettier这里要说一下很多初学者会为了省事跳过ESLint这个我建议不要省。社区平台项目代码量不小没有代码规范约束的话后期排查变量污染、未使用参数这类问题会非常痛苦。ESLint在开发期烦一点点换来的是上线前的省心。装完之后我在src目录下按照功能划分建了以下目录结构src ├── api # 所有接口请求封装 ├── assets # 静态资源 ├── components # 公共组件 ├── router # 路由配置 ├── store # Vuex状态管理 ├── styles # 全局样式 ├── utils # 工具函数 └── views # 页面级组件这个结构看起来很常规但有一个很重要的好处页面组件和公共组件严格分离。页面组件放在views里强调的是一个路由对应一个页面容器公共组件放在components里强调的是可复用、无业务耦合。后面权限控制、页面复用的时候这种边界会帮你省去大量重构时间。2.3 常被忽略的全局样式和主题变量社区健康服务平台面向的是居民用户页面视觉要给人干净、可信赖、亲和的感觉所以我没有用那种深色科技感的模板而是自己定了一套偏医疗浅色系的主题变量。在styles/variables.scss里我定义了$primary-color: #2B8DE0; $success-color: #28A745; $warning-color: #FFC107; $danger-color: #DC3545; $text-main: #333333; $text-sub: #666666; $bg-light: #F5F8FC; $border-color: #E8ECF1; $shadow-light: 0 2px 12px rgba(0, 0, 0, 0.06);把颜色和阴影都收口到变量里看起来是件小事但当页面数量超过二十个之后这个习惯就能体现价值了——改主题色只需要改一个文件而不是满项目地搜索替换。3. 核心业务流程与后端接口联动设计前端的页面只是壳壳里跑的数据才是系统的灵魂。我在做VUE应用时有个习惯先把后端接口文档或者Mock数据约定好再开始写页面。这样可以避免接口字段对不上、前端一遍遍返工的情况。3.1 用一个极简的JSON结构聊健康档案设计健康档案是社区健康服务平台里最核心的数据对象。它的字段设计不能只考虑存什么还要考虑前端怎么展示、医生怎么解读。我设计的基础信息结构大致如下{ id: 1, userId: 12, name: 张女士, gender: 女, birthday: 1978-06-15, height: 163.4, weight: 58.7, bloodType: A型, allergyHistory: 青霉素过敏, chronicDisease: 高血压, familyHistory: 母亲有糖尿病史, lastCheckDate: 2024-09-12 }字段本身不难难在过敏史和既往病史这种自由文本字段前端展示时要做空值兜底和超长截断。我在页面上接数据时发现有记录里存了很长的描述文本如果没有加CSS截断整个卡片都会被撑得很难看。体检报告这块很多人会纠结要不要做多文件上传。我的做法是既支持PDF报告上传也支持录入关键指标数据。这样既照顾了整份报告上传归档的完整性也满足了快速录入关键指标用于可视化分析的需求。3.2 预约服务的状态机设计预约模块是社区健康服务平台里把前后端逻辑串起来最多的一个模块也是我认为最值得认真设计的模块。预约状态的流转我设计成了这样居民提交预约申请 - 状态为待确认医生确认接诊 - 状态为已通过医生拒绝预约 - 状态为已拒绝并附带原因居民在医生确认前取消 - 状态为已取消预约日期已过且状态为已通过 - 系统自动将其视为已完成预约日期已过且状态为待确认 - 系统自动将其视为已过期这个状态机就是很典型的业务逻辑抽象。前端在做按钮显隐的时候非常依赖这一套设计computed: { isPending() { return this.appointment.status PENDING; }, canCancel() { return [PENDING, CONFIRMED].includes(this.appointment.status); }, canReview() { return this.appointment.status COMPLETED; } }这里也顺便说一个经验前端展示用的状态文案最好单独做一层映射后端只传状态码前端根据语言环境转换成待确认已通过已完成这样的展示词。初期可能觉得多此一举但只要后面你想支持医生端今天的日程视图、居民端的历史预约页就会发现这种解耦非常舒服。3.3 接口层的axios封装与Token过期处理接口请求的封装质量直接决定整个平台的稳定性。我没有在每一个页面里去写this.$http.get(...)而是统一封装了一层。我在api/request.js里做了这样几件事创建axios实例设置基础URL和超时时间请求拦截器统一携带Token响应拦截器统一解包数据处理HTTP状态码和业务状态码的区分对401状态统一做登出处理并跳转到登录页。当时一个比较有体会的点是业务状态码和HTTP状态码一定要分开。比如后端因为字段校验失败返回了一个400但前端如果笼统地按HTTP错误处理就很难弹出一个像样的提示更好的做法是后端统一返回JSON结构状态码放在body里HTTP层只管传输成功与否。具体封装的代码大致长这样import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use( config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) ) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service这样的封装还有一个好处后面如果要做权限控制只需要在拦截器里再加一段角色判断逻辑不需要改动所有业务页面代码。4. 可视化看板与数据统计的实现思路社区健康服务平台如果没有数据统计就跟普通的CMS系统没什么区别。我决定加一个数据看板让管理员一眼能看到当前社区的整体健康情况、预约趋势和档案覆盖进度。4.1 ECharts在VUE中的集成方式可视化部分我选择了ECharts。原因也很简单资料多、示例多、图表类型全还支持按需引入。封装一个基础的图表组件很关键。我在components/ChartCard.vue里做了这样一个抽象template div classchart-card div classchart-title{{ title }}/div div refchartRef classchart-content/div /div /template script import * as echarts from echarts export default { name: ChartCard, props: { title: String, option: Object }, data() { return { chart: null } }, watch: { option: { handler(val) { this.chart.setOption(val) }, deep: true } }, mounted() { this.chart echarts.init(this.$refs.chartRef) this.chart.setOption(this.option) }, beforeDestroy() { this.chart.dispose() } } /script封装的好处是页面里只需要这样写chart-card title近六个月预约趋势 :optionlineOption/chart-card然后lineOption由具体页面去维护。这样一来公共的初始化和销毁逻辑都在组件里页面只需要关心数据本身。这个组件的封装逻辑对于我后面做更多的报表分析非常有用。4.2 看板图表的数据清洗可视化最难的不是画图而是让数据好看、有用。我的后台看板做了这几个图表近6个月预约数量趋势图折线图不同科室服务预约占比饼图居民健康档案完整度分布柱状图最近一周新增注册用户数面积图以预约趋势图为例后端接口返回的数据可能是这样的{ code: 200, data: [ { month: 2025-03, count: 46 }, { month: 2025-04, count: 52 } ] }前端拿到的数据直接塞给ECharts其实有一个隐患如果某个月份一条预约都没有后端按聚合分组后就会缺少该月份的记录图表上就直接断掉了。这不是后端的问题而是可视化场景下前端必须做的补零处理。我写了一个工具函数来做补零function fillMonthGaps(records, months) { const map {} records.forEach(item { map[item.month] item.count }) return months.map(month ({ month, count: map[month] || 0 })) }这个细节看似很小但直接决定看板数据是否完整。当时我和后端同学对接口时没有提前约定等渲染出来才发现断点问题。这也是我想跟大家强调的前后端数据契约一定要提前商量清楚尤其是聚合统计类的接口缺省值比你想的更容易出现。5. 权限控制、路由守卫与菜单动态生成社区健康服务平台涉及三种角色如果每个页面都自己用v-if判断角色代码会变得极其难以维护。我采用的是基于Vuex和动态路由的权限控制方案。5.1 登录后动态生成可访问路由VUE项目里静态路由通常只放/login、/404这种公共页面。登录成功后根据用户角色返回对应的权限列表然后router.addRoutes动态挂载业务路由。我这里做了一个简化版的权限映射。下面是一个示例结构const roleRoutes { ADMIN: [ { path: /admin, component: () import(/views/admin/Layout.vue), children: [ { path: dashboard, component: () import(/views/admin/Dashboard.vue) }, { path: user-manage, component: () import(/views/admin/UserManage.vue) } ] } ], DOCTOR: [ { path: /doctor, component: () import(/views/doctor/Layout.vue), children: [ { path: appointments, component: () import(/views/doctor/AppointmentList.vue) }, { path: records, component: () import(/views/doctor/RecordManage.vue) } ] } ], RESIDENT: [ { path: /resident, component: () import(/views/resident/Layout.vue), children: [ { path: profile, component: () import(/views/resident/HealthProfile.vue) }, { path: appointments, component: () import(/views/resident/MakeAppointment.vue) } ] } ] }这里有一个很容易踩坑的细节addRoutes之后要调用next()但next里不能带目标路由地址否则可能会出现循环导航警告。实际开发时我被这个问题困扰过一段时间最后查清楚了是因为addRoutes是异步的如果用户刷新页面后直接重进一个深层链接路由匹配还没完成就会报redirected when going from ... to ... via a navigation guard的警告。建议的写法是在全局守卫里等待路由就绪router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token) { if (to.path /login) next() else next(/login) } else { if (store.state.isRoutesAdded) { next() } else { // 这里异步拉取用户信息并addRoutes } } })还要补充一点每次刷新页面后Vuex里面的动态路由会丢失需要重新生成。所以强烈建议把动态路由的生成逻辑抽到独立函数里不要和登录逻辑耦合在同一个方法里。5.2 按钮级别的权限控制除了页面级别的路由控制一些关键操作也要做按钮级别的权限控制。比如只有管理员才能删除用户只有医生才能编辑健康档案。我的做法是写了一个自定义指令Vue.directive(permission, { inserted(el, binding) { const requiredPermission binding.value const userPermissions store.state.user.permissions if (!userPermissions.includes(requiredPermission)) { el.parentNode el.parentNode.removeChild(el) } } })然后在按钮上这样使用el-button v-permissionuser:delete typedanger删除/el-button这种指令式写法很干净也比在页面里到处写v-if要更容易维护。不过有一个坑就是如果用v-if条件去控制显隐那么用v-permission指令移除的DOM就不会再回来了。所以我通常在实现时会把v-permission和v-if搭配使用保证条件更新时重新渲染。5.3 前端权限不等于数据安全这一点必须说清楚**前端的权限控制只是为了用户体验和界面整洁真正的权限控制一定是在后端完成的。**在做这个项目的时候后端每个接口都会校验当前登录用户的角色前端隐藏按钮只是一种展示层的策略。如果哪个接口只靠前端隐藏就以为安全了那上线之后一定会出问题。6. 开发期踩坑实录路由懒加载、项目结构沉淀与页面渲染这个项目做下来有两三个问题非常典型值得单独拿出来说说。6.1 首屏加载优化与路由懒加载社区健康服务平台页面数量多如果不做懒加载打包出来的app.js会非常大首屏加载白屏时间会特别长。VUE 2中通过动态import实现路由懒加载在很多人的认知里已经是常识了但我想讲一个更深一点的坑懒加载和静态资源分组策略不搭的话会生成非常多奇奇怪怪的chunk文件导致加载顺序乱掉。我的做法是在vue.config.js里配置手动分包configureWebpack: { optimization: { splitChunks: { chunks: all, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendors, priority: 10, chunks: initial }, echarts: { name: echarts, test: /[\\/]node_modules[\\/]echarts[\\/]/, priority: 20, chunks: all } } } } }为什么要把ECharts单独抽出来因为ECharts体积真的很大只有看板页面才用得到如果打进主包里非看板页面的用户也要下载这部分内容完全没有必要。单独分包之后只有打开看板页面的时候才会按需加载ECharts相关的chunk。6.2 图片资源懒加载与静态资源处理健康资讯里会大量放科普图片如果首页一次性加载几十张原图页面几乎肯定会被拖慢。我处理的办法是静态资源统一放在assets目录下凡是通过require引入的图片Webpack会处理体积和路径页面中的图片资源给到固定的宽高比并配置懒加载指令对于后端上传的用户头像、体检报告封面统一在存储路径上加缩略图后缀。这个项目里我没有引入第三方懒加载插件而是自己写了一个简单的滚动监听懒加载指令。听课效果还不错感兴趣的可以自己尝试一下。6.3 在刷新页面时保持用户状态的统一方案刷新页面时Vuex会重置这个是VUE项目开发里最经典的问题之一。我的做法是用户登录成功后把基础信息写入localStorage作为持久化缓存并在应用启动时去尝试恢复Vuex状态。简单封装了一个session.jsconst TOKEN_KEY community_health_token const USER_KEY community_health_user export function setToken(token) { localStorage.setItem(TOKEN_KEY, token) } export function getToken() { return localStorage.getItem(TOKEN_KEY) } export function setUser(user) { localStorage.setItem(USER_KEY, JSON.stringify(user)) } export function getUser() { const raw localStorage.getItem(USER_KEY) return raw ? JSON.parse(raw) : null } export function clearSession() { localStorage.removeItem(TOKEN_KEY) localStorage.removeItem(USER_KEY) }这样在main.js启动时可以直接用getUser()初始化Vuex中的用户模块。需要注意存在localStorage里的用户信息只用于前端展示任何涉及安全校验的接口请求后端都必须根据Token重新认证。7. 表格、表单、弹窗等高频组件的工程化沉淀社区健康服务平台有大量的后台管理页面这些页面其实都是同一种套路——左边搜索栏中间表格右边分页点击新增或编辑弹出对话框。如果每个页面都从零写一遍确实太累了。所以我沉淀了一套高频组件的封装方法。7.1 查询表单与表格的组合使用我做了一个SearchTablePage的思路但未必适合所有项目直接抄关键是理解这种组合思维search-form只负责收集查询条件提交时触发loadDatatable只负责展示数据操作列通过插槽暴露给父组件pagination维护当前页、总条数、每页条数变化时重新加载把这三个部分分别拆成组件之后每个管理页面的代码量就减少到一个search配置加一个table配置了。在用Element UI的el-table时有几个细节值得留意el-table的列设置建议在data里用数组配置化而不是硬编码在模板里这样改列、显隐列会方便很多后端返回的total字段注意和分页组件的total属性对齐避免出现数据明明有100条但页面上显示总数为0这种让人摸不着头脑的情况表格操作列固定右侧宽窄要刚好太窄了按钮会被挤得换行。7.2 弹窗表单的双向绑定与校验时机弹窗表单我建议把dialog和form拆开处理不要把所有状态都混在一个对象里。我的习惯是data() { return { dialogVisible: false, formRef: null, form: { name: , phone: }, rules: { name: [ { required: true, message: 请输入姓名, trigger: blur } ] } } }新增和编辑复用同一个弹窗组件时需要格外注意一件事打开弹窗之前要重置表单数据否则上次留下的数据会残留在新的表单里。我在刚刚开始写这个项目时遇到过好几次新增的记录莫名其妙带着上一条的数据就是因为resetFields调用时机不对。正确的做法是openDialog(row) { if (row) { this.form { ...row } } else { this.$nextTick(() { this.$refs.formRef.resetFields() }) } this.dialogVisible true }为什么加$nextTick因为resetFields是Element UI封装的方法它需要表单已经完成渲染、初始值已经被记录下来之后才能生效。如果在dialogVisible还没更新成true时就调用表单组件还没有真正渲染自然无从reset。7.3 图片上传组件的本地预览与服务端回显社区健康服务平台里面涉及居民头像、体检报告封面、健康资讯封面所以图片上传是一个绕不开的点。Element UI的el-upload有很多模式可以选我最终采用的是手动上传的方式用户选择图片后先通过URL.createObjectURL生成一个本地预览地址调用后端上传接口上传成功后拿到图片的URL把URL回填到表单字段里提交整个表单时图片字段已经是一个合法的服务端地址了。这里要注意一个安全问题如果直接用URL.createObjectURL生成的本地地址去提交表单后端是拿不到图片数据的。一定要确保提交给后端的是上传接口返回的真实地址。8. 数据可视化、登录验证、环境配置等剩余隐藏模块核心业务做完之后剩下的这些模块看起来小但对整体体验的影响其实很大。8.1 登录验证码与密码加解密社区健康服务平台面向的是社区居民登录环节如果做得太简陋会显得不正式但也不能复杂到用户不想用。我最终加了一个简单的图形验证码同时在前端对密码做了一次加密处理。密码加密这块要说明一下前端加密不等于后端不用存密文。标准的做法是前端把密码做一次摘要处理后传给后端后端再用更安全的哈希算法加密存储。前端的加密更多是为了防止密码在传输过程中被明文截获但真正扛住脱库风险的还是后端的加密存储。图形验证码我用的是Canvas手绘的简单验证码没有大面积引入第三方库。做法是后端生成4位随机字符存入session前端请求一张图片接口提交时把用户输入和session里的进行比较。这个功能实现起来非常经典而且演示效果好特别推荐在毕设答辩中主动展示。8.2 多环境变量配置项目要能在本地开发、测试服务器、生产服务器之间无缝切换环境变量的配置就得提前做好规划。VUE CLI支持.env、.env.development、.env.production多环境配置。我的配置思路是# .env.development VUE_APP_BASE_APIhttp://localhost:8080/api # .env.production VUE_APP_BASE_APIhttps://api.example.com/api然后axios封装的baseURL直接读取process.env.VUE_APP_BASE_API。这样做的好处是代码里不出现任何环境相关的硬编码URL换环境只需改配置文件不需要重新打包改代码。有一个前端开发很容易踩的坑Vue CLI里的环境变量只能以VUE_APP_开头才能被静态读取。如果你自己随便起了个BASE_URL这样的变量名在代码里取出来永远是undefined。这个细节坑了不少人我自己也被坑过一次。8.3 打包部署检查清单部署时有一份检查清单是很有用的。我每次上线前都会过一遍是否已去掉所有console.log调试输出是否已确认后端接口地址指向的是生产环境是否已检查路由模式是history还是hash如果用了historyNginx是否配置了history回退是否已处理接口跨域生产环境建议通过Nginx反向代理是否已检查打包后的chunk大小首屏加载是否异常尤其是路由模式的坑我在本地用的hash模式一切正常部署到服务器上后用户刷新首页、详情页都出现404。排查到最后发现是history模式刷新时找不到对应的物理文件路径需要在Nginx里配置try_files回退。如果想让部署后的项目没有外链问题推荐用相对路径-base: ./构建这样项目不管部署在子目录还是主域名下都相对安全。9. 我做的数据管理方案从表格到可视化决策社区健康服务平台积累下来的数据不应该只是躺在数据库里。我做了一个轻量级的数据管理方案用来支撑平台运营决策。9.1 居民健康档案完整度指标体系平台越用越久居民档案数据会越来越多。但数据多不等于数据有价值很多档案是残缺的。我在后台做了一个档案完整度指标用来评估每个居民的档案质量。我简单定义了一套规则基础信息完整姓名、性别、生日25分联系方式手机号10分身体指标身高、体重、血压25分过敏史与既往病史20分最近一次体检报告日期距今不超过一年20分总分100分。前端展示的时候低于60分就是待完善60到80分是基本完善80分以上就是完善。这套规则不需要复杂的算法只是简单地加权计算但配合柱状图展示管理员一眼就能看出当前档案管理最薄弱的地方在哪里。9.2 从预约数据中发现的排队高峰在看板上线后我意外发现了一个很有价值的规律社区预约服务的高峰集中在每周一和周二上午尤其是上午9点到11点之间。通过折线图看清这个现象后我在平台里加了一个预约小贴士的提示位告诉居民可以错峰预约。这一个小小的改动就缓解了医生端预约拥挤的情况。这个案例其实是整个项目里比较有亮点的数据驱动决策的体现在答辩时可以好好讲一讲。9.3 数据清理与备份策略虽然社区的并发量不会很大但数据的正确性和可恢复性还是必须保证的。我做了三件比较简单的事定时任务每周日凌晨对用户操作日志做归档超过90天的日志移动到备份表数据库每日自动备份到服务器本地保留最近7天的备份文件接口层对所有删除操作都做软删除标记避免物理删除造成无法追踪。这些虽然是后端的事但作为全栈开发前端也需要知道数据存在哪、什么时候会丢。特别是软删除标记这个设计前端在列表页过滤数据时一定要记得加上deleted_at为空的查询条件否则很容易查到一堆不存在的脏数据。10. 部署上线后的观察与后续迭代思路系统的部署上线不是终点反而是整个项目生命周期里最需要认真对待的阶段。系统跑起来之后我在服务器上做了几轮持续观察也总结了一些非常实在的经验。10.1 运行日志与前端监控前端的JavaScript报错如果不做监控用户那边看到白屏了你都不知道。我在项目里做了很轻量的前端错误采集全局捕获window.onerror和unhandledrejection把错误信息和发生时的当前路由一起发送到后端日志接口后端定时汇总前端错误并生成错误报告在这个项目的实际运行中这个监控帮我抓到了两个问题一个是某型号安卓原生浏览器对String.prototype.replaceAll方法不支持导致页面崩溃。解决的方法是构建时通过Babel做语法降级同时在代码里尽量不用太新的字符串方法改用正则表达式或者split/join组合。另一个是图片懒加载在快速滑动时抖动。后来发现是滚动监听和图片位置计算有偏差最后通过增加加载占位高度和防抖函数解决了。10.2 用户反馈数据驱动的迭代上线一段时间后从留言功能里收集到不少真实的居民反馈。其中比较集中的是体检报告里很多专业术语看不懂。于是我在第2个迭代周期里增加了指标解读模块——每个关键指标都预设了一条通俗易懂的解读文案比如你的血压处于正常范围继续保持良好的作息和低盐饮食习惯。这个功能改动量不大但对居民的价值感提升非常明显。这也让我再次体会到好的软件不是炫技而是真正回应使用者的需求。10.3 下一步可以做些什么如果后续要继续进化这个平台我会从这几个方向去考虑接入慢病随访提醒向有高血压、高血糖管理需求的居民推送打卡提醒增加健康知识个性化推荐根据档案里的慢性病种推荐相关科普内容优化移动端H5体验目前主界面虽然是响应式的但移动端的操作路径还有不少优化空间考虑引入实时消息通知预约状态变化时通过微信服务号模板消息通知居民。这些想法不一定都要在毕业论文的功能范围里实现但它们能体现你对项目的思考深度在毕业答辩里能帮你更好地展示项目的延展性。如果现在再让我回顾这个基于VUE的社区健康服务平台的开发和上线过程我的体会是做一个系统技术都是可以逐步学的但是把需求看得清楚、把边界定得合理、把细节做得扎实才是真正决定这个项目能不能达到预期效果的关键。从最开始选定VUE技术栈、确定三种核心角色到搭建工程目录、封装接口层再到权限动态路由、ECharts可视化看板以及最后的上线监控和迭代优化每一步都有值得复盘的地方。希望我梳理出来的这些设计思路和踩坑经验能让你在开发自己的社区健康服务平台时少走一些弯路把这个选题做成一个真正拿得出手的作品。