1. 项目概述与毕业设计选题思路1.1 为什么选了养老院管理系统这个选题每年到毕业设计选题季很多同学都在纠结到底做什么项目。我当初选养老院管理系统这个题目核心原因有三点第一业务场景足够典型养老院的日常管理包括了老人档案、健康护理、床位分配、费用收缴、家属探访等多个环节每个环节都是清晰的信息管理需求非常适合用SpringBootVue这类主流框架去落地第二需求边界明确系统要解决的就是“信息登记、流程审批、数据统计、权限控制”这几件事不存在开放式算法的坑适合在有限周期内完整交付第三社会价值角度说得通老龄化趋势下养老机构的信息化需求是真实存在的答辩时能讲出实际意义而不是一个空中楼阁。这类管理系统的本质其实就是把线下纸质台账搬到线上把散落在Excel里的数据变成结构化存储把口头交接的流程变成系统化审批。想清楚这一点项目设计就不会跑偏。1.2 技术栈选型的底层逻辑SpringBoot Vue MySQL这套组合在毕业设计里几乎是“标准答案”级别的主流选择。不是说它一定比其他方案强而是它在“开发效率、资料丰富度、答辩说服力、就业衔接度”四个维度上达到了很好的平衡。后端用SpringBoot看中的是它的自动配置能力。相比传统的SSM框架SpringBoot把大量配置收敛成了“约定大于配置”一个启动类加几个注解就可以跑起来一个Web服务这对毕业设计这种时间紧、任务重的场景特别友好。同时SpringBoot集成了Spring MVC、Spring Security、MyBatis等生态后续扩展功能模块非常顺手。前端用Vue核心理由是组件化和响应式。Vue的单文件组件模式适合快速搭建后台管理界面Element UI组件库又提供了现成的表格、表单、弹窗、分页组件不需要从零手写样式。对于不擅长前端的同学来说用Vue Element UI可以在两三天内把页面框架搭出来把更多精力留给后端逻辑。MySQL作为数据库不用多说开源免费、资料多、MySQL Workbench和Navicat都能可视化操作建表、导数据、写SQL都很方便。整个系统只有一套数据库单机部署不涉及分布式这个量级完全Hold住。注意毕设选题时避免一上来就搞微服务、Redis缓存、消息队列这些复杂架构。不是说这些技术不好而是毕业设计的核心目标是“完整、可运行、逻辑自洽”而不是炫技。把SpringBootVue这套基础架构做扎实比引入一堆中间件却说不清原理要安全得多。2. 业务流程梳理与功能模块设计2.1 养老院的真实业务场景拆解我在做需求分析的时候专门去找本地一家养老机构的管理人员聊过了解真实的管理流程。养老院的日常运营有几个核心角色院长/管理员、护士/护理员、财务人员、老人及家属。不同角色关心的数据完全不同。院长关心的核心问题是现在一共有多少位老人哪些人住在哪个房间入住率多少这个月的营收和支出大概多少这些维度是管理报表的核心。护理员需要的是日常任务清单今天要给哪些老人量血压哪些需要定时送药哪些卧床老人需要翻身护理如果这些信息靠脑子记、靠本子写很容易遗漏所以系统里的护理任务模块非常关键。财务人员的痛点是收费床位费、护理费、伙食费、医疗费每月的费用构成很杂还要记录家属已经交了多少钱、还欠多少。手工算账很容易出错。另外一个容易忽略的细节是家属探访记录和老人的紧急联系人管理。老人出现突发状况时能不能第一时间联系到家属这个信息如果登记不全风险非常大。把上面这些需求梳理完之后系统的功能模块基本就清晰了。我在设计时把它们归成了几个大模块系统管理、老人档案管理、床位管理、护理记录管理、费用管理、访客管理外加一个可视化数据看板。2.2 用户角色与权限设计要点毕业设计里权限这块不用做得太重但一定要有RBAC基于角色的访问控制的思想体现。我设计了三个角色分别是超级管理员、护理员、财务专员。超级管理员拥有全部模块的读写权限负责员工账号分配、基础数据维护。护理员只能查看和填写自己负责的老人护理记录、每日巡检台账不能接触财务数据。财务专员只开放费用管理菜单负责缴费登记和账单统计不涉及护理计划。前端通过Vue Router的导航守卫来控制页面路由的访问后端通过Spring Security或拦截器来校验接口权限。两层都做校验而不是只做前端隐藏这一点在答辩时会被问到建议重点准备。前端控制路由的写法大概是这样// 路由守卫 router.beforeEach((to, from, next) { // 判断是否登录 if (to.path ! /login !localStorage.getItem(token)) { next(/login) } else { // 判断角色对应的菜单权限 const role localStorage.getItem(role) if (to.meta.roles !to.meta.roles.includes(role)) { next(/403) } else { next() } } })后端拦截器或者AOP切面里再做一层Controller层校验确保用户就算绕过前端直接调接口也无法越权操作。2.3 核心功能清单与模块划分功能模块我最终定成六个每个模块的边界和针对的角色都做了明确划分模块名称核心功能点适用角色业务价值系统管理用户管理、角色管理、菜单管理超级管理员保障系统安全老人档案入住登记、档案详情、健康信息护理员/管理员老人信息集中化床位管理楼栋-楼层-房间-床位四级结构管理员床位利用率可视化护理记录每日巡检、健康指标录入、用药提醒护理员护理过程可追溯费用管理费用项配置、月度账单、缴费登记财务专员收支清晰透明数据看板入住率、性别比例、年龄分布、费用统计管理员决策支持这几个模块覆盖了养老院运营管理的核心链路老人来了录入档案、分配床位、日常护理记录、每月费用结算属于一条完整的业务闭环。2.4 为什么舍弃了一些看似有用的功能我在设计过程中砍掉了两个功能一个是“线上请假审批”另一个是“家属小程序端”。不是技术上做不了而是“范围蔓延”在毕设里是大忌。每多一个功能意味着前端页面、后端接口、数据库表、测试用例、论文篇幅都要成倍增加。与其做十个半成品功能不如把六个核心模块打磨完整。家属小程序涉及微信开发流程和个人号认证周期不可控。线上请假审批虽然逻辑简单但和核心业务的关联度不高。砍掉这两个功能换来的是整个系统的完成度和稳定度显著提升。实操心得毕设项目的范围最好控制在一个学期内可独立完成的程度核心模块多一些细节打磨比盲目堆功能更划算。答辩时老师追问细节你能答得越细印象分越高。3. 数据库设计与核心表结构解析3.1 数据库建模的整体思路数据库设计这步是整个项目的地基地基没打好后面写代码全是补丁。我遵循了三范式但在费用明细和统计数据上做了适度的冗余设计因为完全的三范式在业务查询时会出现大量多表关联性能和维护成本都高。这个系统的核心关系可以用一句话概括老人是业务主体围绕老人展开床位关系、护理关系、缴费关系。所以老人表是整个数据库的中心节点其他表都通过外键关联到老人ID上。我总共设计了9张表用户表、角色表、老人信息表、家属联系人表、床位表、护理记录表、费用项目表、缴费记录表、登录日志表。下面我挑几个核心表详细说说设计思路。3.2 核心表结构详解老人信息表elder是整个系统最核心的表字段设计除了基础的身份信息、出生日期、联系方式以外还加入了入住日期、护理等级、健康状态、紧急联系人等养老行业特有的字段。CREATE TABLE elder ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, elder_no varchar(32) NOT NULL COMMENT 老人编号如YL20240001, name varchar(50) NOT NULL COMMENT 姓名, gender tinyint(1) DEFAULT 1 COMMENT 性别 1男 0女, birthday date DEFAULT NULL COMMENT 出生日期, id_card varchar(18) DEFAULT NULL COMMENT 身份证号, phone varchar(20) DEFAULT NULL COMMENT 本人联系电话, nursing_level varchar(20) DEFAULT 自理 COMMENT 护理等级自理/半自理/全护理, health_status varchar(500) DEFAULT NULL COMMENT 健康状况描述, room_id bigint(20) DEFAULT NULL COMMENT 关联床位ID, checkin_date date DEFAULT NULL COMMENT 入住日期, emergency_contact varchar(50) DEFAULT NULL COMMENT 紧急联系人, emergency_phone varchar(20) DEFAULT NULL COMMENT 紧急联系人电话, status tinyint(1) DEFAULT 1 COMMENT 状态 1在住 0已退住, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_id (room_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT老人信息表;这里有几个设计细节值得注意elder_no采用“YL年月序号”的编码规则这种业务编号比自增主键更直观导出报表后人工核对也方便。nursing_level虽然是字符串但实际值域固定我前端用下拉框限制输入比单独建一张字典表更简单。紧急联系人字段直接放在老人表而不是单独建表因为一个老人的紧急联系人数量需求一般不超过两个冗余设计换取查询效率是值得的。床位表bed采用了楼栋、楼层、房间、床位四级结构。我用三个字段来表示层级关系而不是做四张关联表。CREATE TABLE bed ( id bigint(20) NOT NULL AUTO_INCREMENT, building_no varchar(20) NOT NULL COMMENT 楼栋号如A栋, floor_no int(11) NOT NULL COMMENT 楼层号, room_no varchar(20) NOT NULL COMMENT 房间号如A-301, bed_no varchar(20) NOT NULL COMMENT 床位号如A-301-1, bed_type varchar(20) DEFAULT 普通床位 COMMENT 床位类型普通/特护, status tinyint(1) DEFAULT 0 COMMENT 0空闲 1已入住, PRIMARY KEY (id), UNIQUE KEY uk_bed_no (bed_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT床位信息表;当时在“要不要做楼栋、楼层、房间三张级联表”这个问题上纠结了一阵。后来想明白了级联表适合平台化产品但毕设项目是单机构场景用字段冗余把层级压在一张表里前端一个级联选择器就能搞定代码量和复杂度都大大降低。床位的status字段要和老人表的room_id字段配合使用分配床位时同时更新两张表我用SpringBoot的事务注解来保证数据一致性。护理记录表nursing_record是后续数据分析和论文核心展示的重点。CREATE TABLE nursing_record ( id bigint(20) NOT NULL AUTO_INCREMENT, elder_id bigint(20) NOT NULL COMMENT 老人ID, nurse_id bigint(20) NOT NULL COMMENT 护理员ID, record_date date NOT NULL COMMENT 护理日期, blood_pressure varchar(20) DEFAULT NULL COMMENT 血压, heart_rate varchar(20) DEFAULT NULL COMMENT 心率, temperature varchar(20) DEFAULT NULL COMMENT 体温, medication varchar(200) DEFAULT NULL COMMENT 用药情况, diet varchar(200) DEFAULT NULL COMMENT 饮食情况, mood varchar(100) DEFAULT NULL COMMENT 精神状态, remark varchar(500) DEFAULT NULL COMMENT 备注, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_elder_date (elder_id, record_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT护理记录表;护理记录表的设计核心在组合索引(elder_id, record_date)因为系统最频繁的查询就是“查看某位老人某段时间的护理记录”这个索引能直接命中查询条件避免全表扫描。费用相关表我拆成了费用项目表和缴费记录表两张。费用项目表定义“床位费”“护理费”“伙食费”等计费项及单价缴费记录表则记录每笔实际交费情况。拆分的好处是费用项目可灵活配置价格调整不影响历史数据。3.3 数据库设计的几个避坑经验数据库这块我踩过几个坑写出来给大家避雷。第一个坑是字符集问题。建库时一定用utf8mb4而不是utf8否则遇到生僻字或者某些特殊符号存不进去。我自己实际遇到过老人姓名里有生僻字导致插入报错的情况排查半天才发现是字符集的问题。第二个坑是日期类型的选择。老人出生日期和入住日期用date就够了不要图省事用varchar否则后面做年龄统计、入住时长计算时全都要STR_TO_DATE转换给自己埋坑。第三个坑是软删除和唯一约束的冲突。我本来给老人表加了is_deleted字段做软删除但身份证号字段又设了唯一索引逻辑删除后想重新入住同一位老人身份证号就冲突了。最后最简单靠谱的方案是状态字段用status表达“在住/退住”退住不等于删除历史数据留着做统计分析。身份证唯一索引的目的是防止重复建档一旦老人退住把档案状态改成“已退住”同时释放床位但身份证号保留在库里。4. 后端接口设计与核心业务实现4.1 后端工程结构规划后端工程我按照标准的Maven结构组织分包方式对毕设来说非常实用com.yanglao.system ├── config // 配置类跨域、拦截器 ├── controller // 接口层 ├── service // 业务逻辑层 │ └── impl // 业务实现类 ├── mapper // MyBatis的Mapper接口 ├── entity // 实体类 ├── dto // 数据传输对象接收前端参数 ├── vo // 视图对象返回前端数据 ├── common // 公共类统一返回结果、异常处理 ├── utils // 工具类统一返回结果类这一步千万别省。我用了一个ResultT泛型类包含code、msg、data三个字段所有接口都返回这个结构。Data public class ResultT { private Integer code; private String msg; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMsg(操作成功); result.setData(data); return result; } public static T ResultT error(String msg) { ResultT result new Result(); result.setCode(500); result.setMsg(msg); return result; } }为什么要统一返回结构第一前端axios拦截器里只需要判断code是不是200就能统一处理错误提示不需要每个接口单独写错误逻辑第二后端如果抛出全局异常也可以通过RestControllerAdvice捕获后统一包装成Result.error返回前端永远拿到结构一致的JSON这对后期维护是巨大的减负。4.2 老人档案模块的业务逻辑实现老人入住登记这个接口是整个系统业务逻辑最集中的地方因为它不是单表插入而是涉及多表联动事务新增老人档案、关联床位、修改床位状态、生成初始账单。Transactional(rollbackFor Exception.class) public ElderVO checkIn(ElderDTO elderDTO) { // 1. 校验老人是否已经存在身份证号判重 // 2. 校验床位是否空闲 Bed bed bedMapper.selectById(elderDTO.getRoomId()); if (bed null || bed.getStatus() 1) { throw new BusinessException(该床位已被占用或不存在); } // 3. 生成老人编号 YL 日期 序号 String elderNo generateElderNo(); // 4. 新增老人信息 Elder elder new Elder(); BeanUtils.copyProperties(elderDTO, elder); elder.setElderNo(elderNo); elder.setStatus(1); elderMapper.insert(elder); // 5. 关联床位信息 bed.setStatus(1); bedMapper.updateById(bed); // 6. 返回组装后的VO对象 return assembleElderVO(elder); }Transactional是这里最重要的注解。试想一下如果新增老人信息成功但床位状态更新失败数据库里就会出现“老人有档案但床位还是空闲”的脏数据后面分配床位就会出问题。加上事务注解后任何一步抛异常都会回滚全部操作保证数据一致性。我另外写了一个专门的BusinessException运行时异常类配合全局异常处理器一旦业务校验不通过就抛出带提示语的异常前端直接弹出错误提示。4.3 费用管理模块的账单生成逻辑费用管理模块中最容易出错的就是“月度账单自动生成”。很多同学会想到用定时任务去跑但对毕设来说定时任务还要考虑触发规则、失败重试等问题复杂度上升不少。我换了个思路按需生成。当财务人员进入某月的费用清单页面时后端动态计算每位在住老人的费用明细算完直接返回不落库。public ListFeeBillVO generateMonthlyBill(String yearMonth) { // 查询所有在住老人 ListElder elders elderMapper.selectByStatus(1); // 查询所有费用项目配置 ListFeeItem feeItems feeItemMapper.selectAll(); ListFeeBillVO result new ArrayList(); for (Elder elder : elders) { FeeBillVO bill new FeeBillVO(); bill.setElderName(elder.getName()); bill.setElderNo(elder.getElderNo()); BigDecimal total BigDecimal.ZERO; ListFeeDetailVO details new ArrayList(); for (FeeItem item : feeItems) { BigDecimal amount item.getPrice(); // 护理费用根据老人护理等级动态计算 if (护理费.equals(item.getItemName())) { amount calcNursingFee(elder.getNursingLevel()); } total total.add(amount); // 组装明细 } bill.setTotalAmount(total); bill.setDetails(details); result.add(bill); } return result; }按需生成的好处是逻辑简单、不容易出错但也存在一个短板如果费用配置变了上个月的账单也会跟着变。实际使用时我会在确认账单后调一个“确认入账”接口把账单快照写入数据库后续改动不再影响已入账的数据。这个逻辑在论文中写出来很加分体现了对业务场景的思考。5. 前端页面实现与开发要点5.1 Vue工程的搭建与路由设计前端工程我使用Vue CLI搭建配合Vue Router和Vuex做状态管理UI组件库选的Element UI。整个工程结构如下src ├── api // axios请求封装 │ ├── elder.js // 老人档案接口 │ ├── bed.js // 床位接口 │ └── fee.js // 费用接口 ├── router // 路由配置 ├── store // 全局状态 ├── views // 页面组件 │ ├── dashboard // 数据看板 │ ├── elder // 老人管理 │ ├── bed // 床位管理 │ ├── nursing // 护理记录 │ └── fee // 费用管理 ├── components // 公共组件 └── utils └── request.js // axios实例封装axios实例封装时我统一设置了baseURL和请求拦截器在请求头中自动携带token响应拦截器统一处理后端返回的Result结构。这样每个API模块的代码非常精简比如老人模块的接口文件import request from /utils/request // 老人分页查询 export function getElderList(params) { return request({ url: /api/elder/page, method: get, params }) } // 老人入住登记 export function checkIn(data) { return request({ url: /api/elder/checkin, method: post, data }) }5.2 关键页面组件的实现细节老人档案列表页是整个系统最基础的页面包含了表格展示、条件查询、分页、弹出框编辑等常见场景。我用Element UI的el-table组件渲染列表用el-pagination组件做分页条件查询通过绑定表单数据后重新调用查询接口实现。分页操作时有个前后端配合的关键点后端接口的入参是pageNum和pageSize返回的数据结构中除了列表数据还要包含total总记录数前端拿到total后赋值给分页组件的total属性。这个写在代码里很简单但新手经常搞混。护理记录录入页我用了动态表单的写法一次可以连续录入多位老人的巡检数据然后批量提交。这个交互设计在展示环节特别加分答辩演示时能直观体现出系统的实用性。5.3 前端排坑记录第一个坑跨域问题。前端跑在8080端口后端跑在8081端口直接请求后端接口会被浏览器的同源策略拦截。解决方式是后端配置CORS跨域代码里加上相关配置即可。网上还有一种常见做法是在Vue的vue.config.js里配置devServer的proxy代理把/api开头的请求转发到后端地址。两种方案我都试过推荐用后端CORS方案部署时更省心。第二个坑日期格式化。后端返回的日期格式是yyyy-MM-dd HH:mm:ss但部分接口返回的LocalDateTime会被序列化成2024-05-20T10:30:00这种带T的ISO格式。处理方式是在后端配置Jackson的日期序列化格式保证所有接口返回统一格式。第三个坑请求超时。数据看板接口因为要聚合多个数据源加上首次查询没有缓存响应时间有时会超过5秒。前端axios默认超时是0不超时但浏览器长时间等待给用户的体验极差。我的方案是给数据看板接口单独设置了10秒超时同时前端加上loading动画用户感知会好很多。6. 前端页面实现与交互细节6.1 页面框架与技术要点前端我选了Vue 2 Element UI这套组合。不是说Vue 3不好而是毕设场景下Vue 2的生态更成熟网上资料多遇到问题搜起来也快。Element UI对后端出身的同学特别友好表格、表单、弹窗、上传组件都是现成的样式统一不需要自己写CSS。工程结构按模块划分每个模块一个文件夹包含列表页面、编辑弹窗、API定义三个部分。路由用Vue Router通过路由守卫拦截未登录用户。6.2 老人档案页面的核心交互老人档案列表页包含搜索栏、操作按钮、表格、分页四块。搜索支持按姓名、护理等级、状态查询前端把查询条件拼成对象传给后端后端用MyBatis动态SQL拼条件。表格中的状态列我用el-tag组件做颜色标签在住显示绿色退住显示灰色。操作列包含查看详情、编辑、分配床位、退住、缴费记录五个按钮。老人详情用抽屉组件展示左侧放照片右侧放基本信息、健康信息、联系人信息。6.3 数据看板页面的可视化方案数据看板页面我用了ECharts做可视化图表类型包括饼图性别比例、柱状图每月入住人数趋势、折线图本月费用收入趋势。这些组件的核心代码如下// 性别比例饼图 const chart echarts.init(document.getElementById(genderChart)) const option { tooltip: { trigger: item }, series: [{ type: pie, data: [ { value: maleCount, name: 男 }, { value: femaleCount, name: 女 } ] }] } chart.setOption(option)ECharts统计的源数据是从后端专门的统计接口拿到的我在后端写了对应的SQL例如统计各护理等级的人数时使用GROUP BY语法SELECT nursing_level AS level, COUNT(*) AS cnt FROM elder WHERE status 1 GROUP BY nursing_level数据看板的图表加载要考虑页面初始化时机我是在mounted钩子里调接口拿到数据后分别填充到对应的图表option里。这里有个小技巧图表容器如果初始宽度为0或者容器被隐藏过渲染出来会变形需要在容器显示后调用chart.resize()方法。7. 部署上线流程与常见环境坑7.1 本地开发环境搭建环境搭建这一步看起来琐碎但很多同学卡在最开始。需要准备的工具清单如下JDK 1.8毕设项目用1.8最稳高版本JDK配SpringBoot旧版本可能出兼容问题Maven 3.6Node.js 14Vue 2项目建议用Node 14或16更高版本有时候会有依赖兼容问题MySQL 5.7或8.0Navicat或MySQL Workbench可视化操作数据库开发工具IDEA后端、VSCode前端数据库初始化的时候直接执行我提供的yanglao.sql脚本就行。需要注意的是执行前先创建一个空数据库编码选utf8mb4然后选择该数据库再执行脚本。前端工程启动# 安装依赖 npm install # 本地开发启动 npm run serve后端工程启动前需要先改配置文件里的数据库连接信息确保用户名密码和你本机一致。7.2 服务器部署全流程很多同学以为项目能本地跑起来就行了其实部署到服务器是答辩展示时最稳妥的方案。买一台云服务器后部署流程并不复杂核心是三步后端打jar包、前端打dist包、配置Nginx。后端打包mvn clean package -DskipTests打完包后在target目录下生成一个jar文件。把jar传到服务器上用nohup命令启动nohup java -jar yanglao-server.jar --server.port8081 app.log 21 前端打包npm run build会在dist目录生成静态文件把整个dist目录上传到服务器的指定目录比如/usr/share/nginx/html。最后配置Nginx反向代理将前端请求转发给后端server { listen 80; server_name your_domain_or_ip; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这个配置里有两个重要细节前端是history模式的路由所以try_files要指到index.html否则刷新页面会404。后端接口统一以/api开头Nginx把该路径的请求转发到8081端口这种路径前缀区分前端的做法可以避免静态资源和后端接口的冲突。7.3 部署过程中遇到的经典问题部署时常遇到的一个问题后端启动失败但没报明显错误查看日志发现端口被占用。用命令查一下占用进程并kill掉或者直接换端口都能解决。另一个常见问题是云服务器安全组未放行端口。控制台配置了8081端口但访问不通十有八九是安全组策略没有添加规则。记得同时放行80Nginx和8081后端。MySQL远程连接失败也经常遇到。检查两处一是MySQL的bind-address配置二是用户表的host字段。默认创建的root用户host可能只允许localhost登录需要执行授权SQL允许远程访问。GRANT ALL PRIVILEGES ON *.* TO root% IDENTIFIED BY 你的密码; FLUSH PRIVILEGES;8. 论文撰写的重点方向与答辩展示策略8.1 论文框架的搭建思路一份毕业设计论文通常包含七个章节绪论、相关技术介绍、系统需求分析、系统概要设计、系统详细设计、系统实现与测试、总结与展望。这里有个常见的误区很多同学把重点放在技术堆砌上花大篇幅介绍SpringBoot是什么、Vue是什么但老师在答辩时真正关心的是你的业务逻辑、需求分析的合理性以及系统设计的完整性。所以在论文中要重点写清楚系统存在哪些角色、每个角色的核心诉求是什么、这些诉求怎么转化为功能模块、每个模块对应的表结构设计及接口设计。8.2 测试部分的写法系统测试是论文中分量很重的部分。测试内容包括功能测试、性能测试、兼容性测试三块。功能测试针对每个模块的每个功能点罗列测试用例、预期结果和实际结果做一个三列的测试表格。性能测试用说明系统在正常使用场景下接口平均响应时间在XX毫秒以内。兼容性测试说明系统在Chrome、Edge、Safari等主流浏览器上均能正常访问。8.3 答辩演示的动线安排答辩演示的顺序建议这样安排登录页展示角色权限差异数据看板展示统计功能老人档案模块从入住登记到档案查询完整过一遍护理模块录入一条记录费用模块生成账单最后展示部署环境说明系统已能实际运行。有个演示的小技巧提前准备一组完整的测试数据包括不同护理等级的老人、不同月份的缴费记录、近半年的护理日志。别用空数据演示观感差异特别大。答辩时如果老师问“这些数据是哪来的”如实回答是为了测试系统功能构造的模拟数据同时说明系统支持真实的业务数据导入。9. 个人实践体会与踩坑总结整套系统从零到一做完印象最深的还是那些边写边踩的坑。原以为最耗工时的部分是代码实际上最花时间的是需求梳理和数据库设计。一开始我把表结构设计得过于复杂后来一步一步砍掉不必要的映射关系系统反而更清晰了。一个建议是写代码时保持一致的事务边界。多表更新操作记得加事务确保要么全部成功要么全部回滚。另一个建议是务必要做统一异常处理。前期没做全局异常捕获时接口一旦报错前端收到的就是一长串堆栈信息特别难看。关于测试数据的准备建议专门写一个数据初始化接口一次生成几十条测试记录。开发过程中反复测试分页、搜索、统计图表时这套数据能节省大量手动录入的时间。最后一个经验是版本管理的使用。哪怕是一个人写项目我也推荐用Git做版本管理每完成一个模块就提交一次出问题时可以随时回退到上一个稳定版本。我印象很深的一次是改护理模块的功能改着改着把老人列表功能改坏了回退版本后一下恢复正常那种心情比啥都值。这套管理系统最终的成果是一套可运行的代码、一份完整的设计文档和几十张数据表。养老院管理系统这个题目上限很高下限也不低关键看有没有认真把每一个模块想清楚、做扎实。希望这篇分享能给正在做类似选题的同学一些参考和帮助。