每到毕业季总有人私信我“学长社区养老App这种题目怎么做啊能不能带一下”其实这个题我很熟——2026届毕设的社区养老信息App后端走SSMJava老牌技术栈前端配一个App壳外加源码和论文一起交付是很多学校软件工程、计算机技术专业同学的标配选题。这篇文章我就把做这类题目的全过程拆开讲从需求分析、数据库设计到SSM整合、接口实现再到答辩现场最常见的追问一次说透。不管你是刚拿到题目还没头绪还是源码已经跑起来了但论文不知道怎么编这篇都值得看完。这类项目的难点从来不是“写代码”而是“把业务讲圆”。很多同学下载了一份源码跑通之后不知道自己写了什么答辩被老师问两句就卡壳。所以我这儿的思路是先拆业务再讲技术最后排坑让你既看得懂代码也讲得出道理。1. 需求先行这题到底在做什么功能模块怎么拆1.1 先搞清楚社区养老场景里的三个角色社区养老信息App关键词是“社区养老”和“信息”。它不是智能硬件项目不需要你去做心率手环、定位手环的物联网对接核心是把社区养老服务过程中的信息管起来。我接触过不少做这个题目的同学最常犯的错就是一开始就想着上设备、搞报警、做视频通话结果开发量爆炸论文还没法自圆其说。实际上这个场景里只有三类人老人查自己的健康档案、预约上门服务、提交求助留言、看家属是否在线。家属绑定老人档案查看健康数据和服务记录接收服务完成通知。社区工作人员/管理员新建老人档案、维护健康记录、接单派单、回访登记、管理系统账号。想明白这三类人之后这个题目的业务闭环就清楚了建档 → 服务预约 → 派单处理 → 结果记录 → 家属可见。你只需要把这条链路上的信息流打通这个毕设的业务逻辑就完整了。很多高分论文的加分点恰恰是把这条链路讲得清晰而不是堆了多少功能页面。1.2 模块划分别一上来就堆功能很多同学拿到题目就急着列功能清单登录注册、健康档案、服务预约、新闻资讯、紧急求助、留言板、后台管理……全都要。这其实是毕设的大忌。功能一旦超过你能讲清楚的范围论文写起来就是流水账答辩时老师随便挑一个细节问你就容易露馅。我比较推荐的控制规模方式是按角色做功能矩阵先定角色再定每个角色必须有的核心动作其余统统砍掉。下面是我常用的一套模块划分供参考模块使用角色核心动作为什么必须有登录认证全部角色账号密码登录、退出没有登录就没有角色区分这是系统的地基老人档案管理工作人员新增、编辑、查询、删除老人档案整个社区养老业务的主数据所有服务围绕它展开家属绑定老人/家属/工作人员老人关联家属手机号打通“家属查看老人状态”这条链路健康档案管理工作人员录入血压、血糖、体检记录健康数据是社区养老的核心信息资产服务预约老人/家属提交上门助洁、助餐、陪诊等服务体现“服务流转”是业务闭环的关键工单派发与处理工作人员接单、处理、完成、回访让服务预约真正落地而不是只提交不处理数据看板工作人员/管理员今日服务量、健康异常提醒等统计体现“信息”价值也给论文加一个展示亮点这套模块切下来开发量其实不大后端大概四五个实体类、四五个Controller前端每个角色两三张页面就够了。而且每个模块之间都有依赖关系论文的ER图、用例图、时序图画出来也会很饱满不会显得东一榔头西一棒子。1.3 后端为什么用SSM反而是个稳妥选择你可能已经注意到了2026年了网上铺天盖地都是Spring Boot教程为什么毕设还要用SSM我个人的看法是毕设选型首先要考虑的是“老师认不认、参考多不多、你能不能讲清楚”而不是技术是不是最新。SSMSpring SpringMVC MyBatis是Spring Boot出现之前Java Web开发的主流组合也是很多高校软件工程专业课程里还在教的内容。选它有三个实际好处学校老师普遍熟悉答辩时不用费劲解释“为什么不用SSM而用Spring Boot”。网上源码和参考论文极多遇到问题能查到大量相同场景的解决方案。SSM的配置是显式的web.xml、Spring配置文件、MyBatis映射文件都摆在你眼前反而方便在论文里写架构图、写配置文件说明工作量很容易体现。当然如果你导师明确说可以用Spring Boot那改造也很快。SSM理解透彻了切到Spring Boot基本就是“去配置化”的过程核心的注解、事务、依赖注入思路完全一致。所以不用纠结题目指定SSM就按SSM做没指定就看你手里哪个源码完整。这里我多说一句下载的源码一定要先跑起来再改跑通一个项目比你新写一个项目快得多也稳得多。2. SSMJava核心机制拆解框架到底是怎么转起来的2.1 三层框架的分工用餐厅打个比方很多同学一上来就背“SSM是Spring、SpringMVC、MyBatis三大框架的整合”但答辩时被问到“这个框架是怎么工作的”就卡住。其实不需要背源码只要把三层分工用大白话讲明白就行。我把SSM比作一个餐厅Spring就是餐厅的“后勤总管”负责创建所有对象服务员、厨师、收银员还负责管理它们之间的依赖关系。哪个服务员要用哪个厨师不用服务员自己去找总管直接给他。SpringMVC是“前台接待”所有客人HTTP请求进店先由它接待。它根据你点的菜URL地址把请求分发给对应的服务员Controller服务员再把客人的需求转给后厨。MyBatis是“厨师和菜单”负责真正和后厨仓库数据库打交道。Java接口里的方法对应一条SQL语句就像菜单上“宫保鸡丁”对应一份食材和做法你只管点单后厨照单做菜。这三个角色配合起来一次完整的请求流程就是前端页面发起请求 → SpringMVC的前端控制器DispatcherServlet接收 → 找到对应Controller → Controller调用Service层处理业务 → Service层通过Mapper接口让MyBatis执行SQL → 结果一层层返回最终回显到页面或返回JSON给App端。我在实际操练中体会很深的一点是只要能把这条请求链路完整说出来答辩就成功了一大半。老师问框架原理你直接画这条链路再拎出Spring的IoC、AOP说一说基本就是满分回答了。2.2 SSM常用注解做毕设必须吃透的清单SSM框架里注解是绕不开的内容。面试和答辩都喜欢问“你用过哪些常用注解”所以这个清单必须烂熟于心。这里我按使用频率整理了一份都是实际项目里几乎每个类都会用到的注解作用使用场景Controller标记类是SpringMVC的控制器放在Controller类上接收前端请求RestControllerController ResponseBody的合并版前后端分离时直接返回JSON数据Service标记类是业务层组件放在Service实现类上交给Spring管理Repository / Mapper标记数据访问层组件放在Mapper接口上让MyBatis扫描到Autowired按类型自动注入依赖对象在Controller中注入Service、在Service中注入MapperRequestMapping映射请求URL和方法类级别定义模块路径方法级别定义具体接口PathVariable获取URL路径中的参数例如 /elder/{id} 中的 idRequestParam获取请求参数例如 ?keyword张 中的 keywordResponseBody把方法返回值转成JSON输出不加它返回的是视图名加了才返回数据Transactional开启声明式事务加在涉及多表写入的Service方法上这里有个很多新手会踩的坑在Controller方法上忘了加ResponseBody结果接口返回的是字符串“com.xxx.Elder123abc”这种对象地址。原因就是SpringMVC把它当成视图名去解析了没当成JSON输出。前后端分离的项目直接在类上写RestController就能避开这个问题。另外Service层方法上一定要记得加Transactional。社区养老业务里经常出现“新建老人档案的同时保存健康记录”这种多表操作如果中途报错而事务没开启就会出现档案建了、健康记录没存进去这种脏数据答辩时被问到事务问题就会很狼狈。2.3 App端接口设计从JSP到SSM的思路切换这个题目叫“社区养老信息App”所以前端不是传统的JSP页面而是App。但毕设里的App一般有两种做法一是用H5页面套一个App壳比如用HBuilder打包二是用Android原生开发。不管哪一种后端和App之间都是通过JSON接口通信的。我建议所有接口统一返回一个封装了的状态对象让App端好解析。类似下面这种结构{ code: 200, msg: 操作成功, data: { elderId: 1, elderName: 张桂芳, familyPhone: 138****1234 } }后端对应的Java类就是最基础的Result类字段就三个code、msg、data。data用Object类型方便存放任意数据。这个类虽然简单但在论文里可以讲出花来统一返回结构、前后端解耦、异常信息不直接暴露给用户这些都是加分话术。接口路径设计上推荐按资源来命名简洁清晰例如POST /api/elder/add —— 新增老人档案GET /api/elder/list?pageNum1pageSize10 —— 分页查询老人列表GET /api/elder/detail/{id} —— 查询老人详情POST /api/health/record —— 新增健康记录POST /api/order/submit —— 提交服务预约这样的路径一眼就能看懂答辩时画接口文档也方便。路径规范这块别看不上眼很多同学接口路径随手写比如 /queryElderInfo1结果自己写完三天后再看都忘了是干嘛的论文里API表格也没法整理。你在实际开发里养成良好的命名习惯后面写文档、调试、答辩都会省很多事。2.4 构建SSM工程时最容易漏掉的配置项SSM项目跑不起来百分之八十的问题出在配置上。我用SSM做过好几个项目了总结下来最容易漏的配置有这么几处web.xml里DispatcherServlet的url-pattern。写成/是拦截所有请求静态资源也不会放行写成*.do又会有部分请求进不来。我一般建议统一拦截/然后把静态资源单独放行这样最灵活。Spring配置文件的组件扫描。Controller注解是通过SpringMVC的配置文件扫描的Service和Repository是通过Spring的applicationContext.xml扫描的这两套扫描配置漏一个对应的Bean就注入不上。MyBatis的Mapper接口扫描。mapper接口要扫描到mapper XML文件要指定路径两者缺一启动时就会报“Invalid bound statement (not found)”错误。这三处是SSM整合的命门我自己新手阶段在这上面卡了整整两天。后来学聪明了每加一个配置就启动一次看效果不要攒一堆一起测。排查配置问题的时候把Tomcat的启动日志一行行读完哪里有红色报错就先去解决哪个比乱猜快得多。3. 数据库设计与核心表结构实战3.1 表怎么拆才符合养老业务的真实流转数据库设计是论文里浓墨重彩的一笔也是答辩时老师最爱看的部分。社区养老信息App的核心表不需要太多但要能支撑起业务闭环。我按上一节的功能矩阵拆了这么几张核心表t_user系统用户表保存工作人员和管理员账号t_elder老人档案表保存老人基本信息t_family家属绑定表保存家属信息及与老人的绑定关系t_health_record健康档案表保存血压、血糖、体检等健康数据t_service_order服务工单表保存预约的服务项目和流转状态这里我拿老人档案表和健康记录表举个例子建表SQL大概长这样CREATE TABLE t_elder ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 老人档案ID, name VARCHAR(50) NOT NULL COMMENT 老人姓名, gender TINYINT DEFAULT 1 COMMENT 性别 1男 2女, age INT COMMENT 年龄, phone VARCHAR(20) COMMENT 老人电话, address VARCHAR(255) COMMENT 家庭住址, family_phone VARCHAR(20) COMMENT 紧急联系人电话, health_status VARCHAR(255) COMMENT 简要健康状况, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 建档时间, deleted TINYINT DEFAULT 0 COMMENT 软删除标记 0正常 1删除 ) COMMENT 老人档案表;CREATE TABLE t_health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 记录ID, elder_id BIGINT NOT NULL COMMENT 老人档案ID, record_type VARCHAR(20) COMMENT 记录类型血压、血糖、体检等, record_content VARCHAR(500) COMMENT 记录内容, record_time DATETIME COMMENT 记录时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, deleted TINYINT DEFAULT 0 COMMENT 软删除标记 0正常 1删除 ) COMMENT 健康档案表;两张表之间就是elder_id关联的外键关系。这样的表结构在论文里很好表述老人档案是主表健康记录是从表一对多关系。至于为什么外键不用物理外键而是逻辑关联也可以简单说一句“为了扩展性和性能实际项目中常用逻辑外键”这句话放在论文里很显档次。3.2 表结构设计里必须养成的三个习惯我批过不少学弟学妹的毕设代码发现数据库设计好不好跟水平高低关系不大主要看有没有养成几个基本习惯。这里分享三个我认为最重要的每张表都带create_time和deleted字段。create_time方便做统计排序deleted是软删除标记。社区养老业务的健康数据属于溯源性数据一旦录入就不能物理删除只能逻辑标记删除这个设计答辩时可以直接说“符合医疗健康数据的合规要求”。主键统一用BIGINT自增不要用UUID。自增主键在MyBatis里配合useGeneratedKeys特别好用插入后直接就能拿到主键值方便继续插入关联子表数据。UUID当主键在数据量大时索引性能会差而且可读性差。所有金额、数量、状态字段尽量用数值类型不要用字符串。比如服务状态用0、1、2、3表示待接单、服务中、已完成、已取消不要用“待接单”“服务中”这种字符串。用数值的好处是判断方便写代码时一旦打错中文字符就会出bug而用数字加注释就完全没这个问题。这三个习惯看着不起眼但在实际做项目时能帮你减少很多不必要的麻烦。特别是deleted跟create_time这两个字段很多同学建表时图省事不加等做到预约工单状态查询、今日服务量统计时才发现没有时间字段根本没法分组统计只能回头改表改代码一改就是半天。3.3 核心联表查询与动态SQL示例表建好了接下来就是怎么写查询。社区养老App里最典型的一个查询是首页要展示老人最近的健康记录和家属联系方式。这个需求涉及t_elder和t_health_record两张表用一条联表查询就能搞定SELECT e.name, e.address, e.family_phone, h.record_type, h.record_content, h.record_time FROM t_elder e LEFT JOIN t_health_record h ON e.id h.elder_id WHERE e.deleted 0 AND e.id #{elderId} ORDER BY h.record_time DESC LIMIT 1这里用LEFT JOIN而不是INNER JOIN是因为有的老人可能还没有健康记录但档案详情页也要能显示出来最多健康记录部分显示为空。这个细节也可以写进论文的“查询设计”章节体现你对SQL连接类型差异的理解。另一个常见的场景是后台分页筛选工作人员要根据姓名关键字、健康状态、是否绑定了家属等条件筛选老人档案。条件可能为空不能写死SQL这时候MyBatis的动态SQL就派上用场了select idselectElderList resultTypecom.example.entity.Elder SELECT * FROM t_elder WHERE deleted 0 if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testhealthStatus ! null and healthStatus ! AND health_status LIKE CONCAT(%, #{healthStatus}, %) /if ORDER BY create_time DESC /select这种动态SQL在论文里也是很好的素材。你可以专门开一节讲“基于MyBatis动态SQL实现多条件组合查询”把if、where、foreach这些标签的用法各举一个例子工程量看起来就很充实。我自己做项目时也感觉到动态SQL是MyBatis对比普通JDBC最有优势的地方答辩时直接甩这段XML配置比嘴上说“MyBatis很方便”有说服力得多。4. 核心功能实现与论文写作实录4.1 用户鉴权拦截器与登录放行规则社区养老系统分老人、家属、工作人员、管理员多个角色每个角色看的东西不一样所以必须做登录鉴权。SSM项目里最经典的实现方式是写一个拦截器在请求进入Controller之前检查Session里有没有登录用户。拦截器的核心代码逻辑很简单public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser request.getSession().getAttribute(loginUser); if (loginUser ! null) { return true; // 已登录放行 } // 未登录如果是App端请求则返回JSON提示否则跳转登录页 response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); return false; } }然后在SpringMVC配置文件里注册拦截器并配置放行规则。登录接口、注册接口、静态资源这些必须放行其余接口全部拦截。做App接口时有一个容易忽略的坑App端不一定像浏览器一样自动携带Session Cookie很多请求会因为没有Session被判为未登录。我常用的方案是在拦截器里放行登录注册两个接口其余接口都要求请求头携带token后端用拦截器统一解析。毕设里即使你只做了最简单的“登录后把用户信息放进Session”也要在论文里把Session和Token的区别写清楚老师一看就知道你考虑过这个问题。4.2 健康档案录入与首页数据看板健康档案是社区养老信息App的核心业务之一说白了就是工作人员帮老人录入血压、血糖、体检数据老人和家属能在App上查看历史记录。这个功能从技术上来说就是一个新增加一个列表查询没什么高难度但有一个点值得做得更细致最近一条记录的处理。我在做这个模块的时候是给t_health_record表单独做了一个查询语句每次新增记录后首页展示的就是“该老人最近一次的健康记录”。查询语句用ORDER BY record_time DESC LIMIT 1这样老人档案列表页就能直接展示“血压 130/85mmHg”这种即时状态而不是“暂无数据”。这个小细节对用户体验的提升很明显截图放到论文里也能当功能亮点。数据看板是很多同学容易忽略的加分项。其实不需要做多么复杂的大屏只需要在首页统计几个数字今日服务工单数、待处理工单数、累计服务老人数、近期健康记录条数。前端用简单的柱状图或圆角卡片展示后端就写几条COUNT查询-- 今日服务工单数 SELECT COUNT(*) FROM t_service_order WHERE create_time CURDATE(); -- 待处理工单数 SELECT COUNT(*) FROM t_service_order WHERE status 0; -- 累计服务老人数 SELECT COUNT(*) FROM t_elder WHERE deleted 0;这几条SQL语句在论文数据库设计那一章里展示不仅有实际数据支撑还能配合ECharts展示截图视觉上就让老师觉得项目“有头有尾”。我自己做项目时对这块感受很深同一个题目加上数据看板的同学分数普遍比没加的高原因就是这个看板让系统看起来像一个完整的“信息管理平台”而不是几个增删改查页面的堆砌。4.3 服务预约到派单的工单状态流转服务预约是这个项目里最能体现业务逻辑的功能。老人或家属在App上选择服务项目助洁、助餐、陪诊等提交后生成一张服务工单工单状态依次流转待接单 → 服务中 → 已完成 → 已回访。如果是取消则直接进入已取消状态。这个状态流转用数据库的一个status字段就能搞定但代码实现上要注意一点状态的改变必须走Service方法不能直接让前端传什么就存什么。我见过有的同学直接把前端传来的status拿去update数据库结果用户把状态改成“已完成”就跳过了中间步骤业务逻辑全乱套。正确的做法是后端根据当前状态和时间点决定下一步状态。比如工作人员“接单”操作就是把这个工单从0改成1同时记录接单时间和接单人员ID“完成”操作就是从1改成2同时记录完成时间。每次操作只允许一个状态方向不允许乱跳。这个设计虽然简单但体现了业务闭环论文的时序图也有内容可画。如果你还想让论文多一些高级感可以在Service方法上结合Transactional做“接单后自动发送站内通知给家属”这种联动操作。不需要真做短信推送通过系统内消息表存一条记录App端查看消息列表即可。这一来一回业务闭环就更完整了。4.4 论文怎么搭才显得“工作量足、逻辑闭环”源码是拿来交付的论文是拿来通过的。很多代码能力不错的同学栽就栽在论文写得像操作手册。我建议论文按这个结构搭亲测好用第一章 绪论写研究背景和意义。别抄网上千篇一律的老龄化段落要落到“社区养老场景中信息分散、服务过程不透明、家属无法及时了解老人状态”这三个具体问题。第二章 相关技术介绍SSM框架、Java语言、MySQL、App开发技术。这里注意技术介绍要结合项目讲比如“Spring的IoC容器用于管理业务组件依赖降低模块耦合”不要纯背概念。第三章 需求分析画用例图把老人、家属、工作人员的用例分清楚。这是最容易体现工作量的一章把每个角色的用例表列出来再配功能模块图。第四章 系统设计总体架构图可以用B/S结构图加App端接入说明、功能模块图、数据库ER图和核心表结构说明。第五章 系统实现截图加部分核心代码每个模块两三页重点讲解实现思路不要整段贴代码。第六章 系统测试写功能测试用例表包含正常流程和异常流程比如未登录访问接口返回401顺带写点性能上的思考。这套结构下来整篇论文的层次是递进的逻辑线很完整老师看目录就会觉得工作量足。还有一个小技巧论文里的截图一定不要用网上模板的截图用你自己跑通项目后的真实截图。哪怕是同一个源码换个浏览器、改个别名、加一条测试数据截图就不一样查重和观感都好很多。5. 实测排坑记录SSM毕设最容易翻车的几个点5.1 整合期的高频异常与解决清单SSM项目在整合和启动阶段最容易出问题我把这几年带毕设遇到的高频异常整理成一张速查表你遇到了直接对号入座报错现象常见原因解决办法Tomcat启动后404DispatcherServlet配置的url-pattern不对检查web.xml中servlet-mapping的url-pattern是否匹配请求路径Bean注入报错提示找不到类Spring扫描包路径配置错误检查applicationContext.xml中component-scan的base-package是否覆盖了实际包名Mapper方法报 Invalid bound statementMapper接口扫描到了但XML没扫描在Spring配置中同时配置mapper-locations指向XML目录页面或接口返回乱码编码格式不一致数据库连接URL加characterEncodingutf-8项目文件统一UTF-8500错误日志提示驱动类找不到MySQL驱动jar未导入或版本不对检查pom.xml或lib目录下的mysql-connector-java版本静态资源加载不出来拦截器或DispatcherServlet拦了静态资源配置mvc:resources放行css/js/images这些坑我无一例外都踩过。我的排查心得是先看Tomcat的完整启动日志找到第一行红色的Exception定位到具体类再改代码别上来就全局搜答案。很多时候报错信息里已经把问题点写在第一行了你只要打开对应的类文件看一眼就能修好。另外修改Spring配置文件后一定要重启TomcatSSM项目没有热加载那一说不重启就是拿旧配置在跑白等半天。5.2 数据库与MyBatis侧的经典问题数据库这侧的坑大部分集中在MyBatis映射和时间类型上。最常见的问题是插入数据成功后主键没自动回填。比如新增老人档案后要立刻拿eldId去插入健康记录结果elderId是0或null。这是因为MyBatis插入语句没有开启主键回填。解决方法是在insert标签上加两个属性insert idinsertElder useGeneratedKeystrue keyPropertyid INSERT INTO t_elder (name, gender, age, phone) VALUES (#{name}, #{gender}, #{age}, #{phone}) /insert这里的useGeneratedKeys表示使用数据库自增主键keyProperty指定把生成的主键赋值给实体类的哪个字段。这个方法在论文里讲动态SQL时也能顺便提一句属于实战型技巧。另一个高频问题就是日期时间格式化。数据库里的record_time是datetime类型查出来到Java里可能是java.sql.Timestamp返回给App时默认格式是“2026-04-08 10:30:00.0”多出一个小数点后的0前端展示很丑。解决方式有两种要么在SQL里用DATE_FORMAT函数格式化成字符串要么在Java实体类时间字段上写JSON格式化注解。我实际操作中更推荐后者代码里统一处理比到处改SQL可控。5.3 移动端联调时的几个隐藏雷区既然题目叫“社区养老信息App”就少不了一端是App或移动端H5场景。联调阶段有几个隐藏雷区踩一个浪费一下午跨域问题。如果你用HBuilder打包的App或浏览器页面直接访问后端接口前端和后端端口不一样就会有跨域报错。SSM项目里最简单的处理方式是写一个CORS过滤器在响应头加上跨域允许配置或者用JSONP兜底。这里我强烈建议直接在后端写一个CorsFilter统一放行所有跨域请求毕设阶段图的就是省事稳定。请求头问题。App端有些请求会带上自定义Header比如token如果后端没有配置Access-Control-Allow-Headers浏览器会把这个请求当成预检失败导致接口一直404或者401。这个问题排查起来特别隐蔽因为后端日志什么都没打实际是请求根本没到Controller。图片上传路径问题。如果做老人头像上传保存到本地磁盘没问题但要记得配置一个虚拟路径映射否则App里显示不了图片。Tomcat里加一个Context配置或者用SpringMVC的mvc:resources映射图片目录即可。这三个问题都属于“日志上看不到、但前端就是调不通”的类型出现时优先怀疑跨域和拦截器不要急着查SQL。我自己的排查顺序一般是看Network面板请求有没有发出去 → 看返回状态码 → 看后端有没有请求日志 → 最后再看SQL。一套下来基本五分钟内能锁定问题。最后再分享一个我从实践里总结出来的经验。做这种毕设项目一定要尽早把登录注册、基础增删改查、分页查询这三件套跑通它们是整栋大楼的地基。地基稳了后面加健康档案、服务工单、数据看板都只是往上垒墙速度会越来越快。很多同学前期磨磨蹭蹭到了还有三周交论文的时候才开始焦虑其实完全没必要——SSM技术本身并不难资料的查错链路非常成熟关键是你要先让项目转起来再用项目去倒推论文怎么写这样的节奏才是稳妥的。希望这篇聊下来能帮你少走几步弯路一次把毕设做得明明白白。