微信小程序居家养老毕设：从需求到答辩的完整实战拆解

每年到毕业季总有学弟学妹拿着同一个问题来找我“想做一个微信小程序的毕业设计居家养老方向有没有完整能跑的源码最好连论文一起搞定。”说实话居家养老这个选题在我带过的毕设里属于出镜率相当高的一类原因很简单它既有业务复杂度可以写论文又能在小程序端做出看得见摸得着的界面效果加上微信生态本身自带传播属性答辩演示时不会冷场。但大多数同学卡住的点并不是“不会写代码”而是不知道一个毕业设计级别的居家养老小程序到底该做哪些功能、后端接口怎么设计、数据库建几张表、代码写到什么程度才算“能答辩”。这篇文章我就拿自己实际搭建过的“基于微信的居家养老小程序”项目来完整拆一遍从需求分析到技术选型、从数据表设计到关键代码实现、从联调坑点到答辩话术尽量把能够直接参考复现的部分都给到。适合正在做计算机毕业设计选题的同学也适合想快速搭一个微信小程序原型产品的人参考。项目本身是“源码LW文档”的交付模式我下面讲的都会对应到论文和代码的编写思路方便你直接往自己的文档里套。1. 项目整体设计与需求拆解1.1 居家养老场景到底要解决什么问题老年人养老目前主要有机构养老、社区养老和居家养老三种形态。居家养老指的是老人在自己家里居住由社区或第三方服务机构提供上门助餐、助洁、助医、康复护理、紧急救援等服务。之所以成为毕设热门方向是因为它的业务链条足够完整有老人端、子女端、服务人员端、管理后台天然适合做多角色小程序系统。做毕业设计前先要搞清楚一个核心问题你做的系统是“给谁用”的。很多同学一上来就想把功能做多结果老人端做了个商城、子女端做了个社交、管理员端做了个报表最后自己都解释不清业务闭环。居家养老小程序的核心闭环只有一条老人在家发起服务请求平台派单给服务人员服务人员上门完成后核销订单子女和家属可以远程查看服务记录和老人状态。所有功能都应该围绕这条主线展开其他都是锦上添花。1.2 用户角色怎么拆、功能边界在哪里我通常建议把角色拆成四类对应小程序端和管理后台两个子系统老人用户端这是最核心的C端要照顾到老年人手机操作能力偏弱的现实。功能上不要做复杂交互做成大图标、大字体、少层级。核心功能是服务下单、服务进度查看、紧急求助一键呼叫、健康数据查看子女帮填或设备同步。子女/家属端许多老人其实不会用小程序实际的操作者是子女。所以这个小程序还要具备“代老人下单”的入口。子女绑定老人账号后可以看到老人的服务记录、健康数据、是否完成每日打卡等。服务人员端通常用同一个微信小程序通过角色切换实现或另开一个独立小程序。服务人员需要接单、查看服务详情、上门签到、服务完成确认。PC管理后台一般用Vue或原生HTML搭用于服务项目管理、订单管理、人员管理、投诉处理、数据统计。毕设阶段不用做太复杂能支撑核心业务流程即可。这里有一个很容易掉进去的坑老人端和服务人员端都做成同一套小程序会让你后面被答辩老师追问“角色权限怎么控制的”所以建议在小程序入口做一个“身份选择”界面老人/家属端选择“我是老人/家属”服务人员选择“我是服务人员”后续所有请求根据角色标识返回不同页面和数据。这样权限模型清晰代码也好写。1.3 功能清单与优先级排序毕业设计的工期通常只有两到三个月功能一定得排优先级。我建议把功能分成P0/P1/P2三档优先级功能模块具体内容P0用户登录微信授权登录、手机号绑定、家庭成员绑定P0服务浏览与下单服务分类展示、服务详情、预约时间、提交订单P0订单管理订单列表、订单详情、取消订单、订单状态流转P0紧急求助一键呼叫紧急联系人、SOS消息推送P1健康档案血压/血糖/心率记录、历史趋势、提醒打卡P1服务人员端接单列表、上门操作、完成确认P1管理后台订单管理、服务项目管理、数据统计P2服务评价老人对服务进行评分与文字评价P2消息通知订阅消息、服务进度通知、用药/复检提醒P0的功能必须在中期检查前全部实现P1保证核心闭环P2留有余量。我见过太多同学把时间花在做商城页面上最后发现主流程都没走通这是最可惜的事。2. 技术选型与架构设计2.1 小程序前端原生还是uni-app这是做微信小程序毕设遇到的第一个选择。给个明确结论如果不是你已经有充分的Vue经验老老实实用微信小程序原生开发。原生小程序语法就是WXMLWXSSJSJSON微信开发者工具里写什么是什么出问题网上随便一搜就有答案。用uni-app的好处是一套代码多端复用但代价是你要额外理解Vue的响应式机制、uni-app的编译差异、各平台API兼容这会把很多不必要的心智负担带进毕设项目。反过来讲如果你已经熟练Vueuni-app确实能让代码组织更舒服而且很多毕业设计题目要求“跨平台”那么uni-app更合适。我当时帮学生做的时候选的是原生因为答辩老师翻代码时能直接看到wx.request、Page({})这些熟悉的微信API提问难度会低一些。2.2 后端与数据库选型后端选择上Java Spring Boot MySQL是计算机专业毕设的主流配置也是最保险的组合。Spring Boot生态成熟网上关于登录鉴权、MyBatis-Plus操作、Swagger接口文档的教程非常多踩坑好查。如果你对Java不太熟也可以用Node.js的Express/Koa或Python的Flask/Django来写但是论文里的“技术选型”部分要想好怎么去比较和解释。数据库我一般建议MySQL。原因很朴实所有毕设相关的教学资料、开源项目、答辩PPT模板默认都是MySQL数据导入导出方便面试聊起来也通用。数据库管理工具推荐Navicat或DBeaver可视化操作建表导数据都省心。至于要不要引入Redis我的建议是别加。毕业设计阶段引入Redis做缓存只会增加部署和答辩复杂度除非你想在论文里多写一个技术难点否则一个单机MySQL足够应付所有场景。2.3 前后端交互与接口设计思路小程序端通过HTTPS请求调用后端接口后端返回统一JSON结构。这里要提前约定好返回格式我一般使用{ code: 200, message: 操作成功, data: { } }code用200表示成功、500表示业务异常、401表示未登录小程序前端统一判断code后做提示。这个结构虽然简单但胜在统一前端封装的请求方法里只要写一次拦截逻辑后面所有接口都能自动处理错误提示。接口路径设计上按资源划分比如POST /api/user/login微信登录GET /api/service/list服务列表POST /api/order/create下单GET /api/order/myOrders我的订单GET /api/health/list健康记录前后端分离的项目接口文档可以用Swagger自动生成也可以自己维护一个Markdown表格毕设答辩时不需要把Swagger UI做得天花乱坠接口清晰即可。3. 核心功能与数据模型设计3.1 老人端核心业务流程拆解整个系统最核心的流程是“下单—派单—服务—完成”的闭环。以陪诊服务为例家属在小程序里选择“陪诊服务”填写老人的姓名、地址、预约时间、病情备注提交后生成待支付订单管理后台或服务人员端看到新订单后确认接单到了预约时间服务人员上门在小程序里点击“开始服务”服务完成后点击“完成”订单状态变为待评价家属评价后订单关闭。养老服务存在多种计费方式有的按小时计费所以服务项目表要设计“计费类型”字段支持按时计费和按次计费。老人在家常用的另一个高频功能是紧急求助。这个功能不复杂但设计上要考虑低门槛操作首页最显眼的位置放一个SOS按钮点击后弹窗确认确认后调起微信订阅消息向老人的紧急联系人发送通知。订阅消息的触发条件是一次订阅一次推送所以在老人或者家属绑定紧急联系人时就要引导用户多次授权订阅否则后面推送配额不够用。3.2 数据库表设计可直接抄数据库表不建议超过12张合理的设计是9到12张既能体现业务完整性又不会把自己卷死。下面是我实际用过的一个表结构字段做了精简表名用途核心字段user用户表id, openid, nickname, avatar, phone, role, bind_family_idelderly_info老人档案表id, user_id, name, age, address, emergency_contact, emergency_phone, health_statusservice_category服务分类表id, name, icon, sortservice_item服务项目表id, category_id, name, price, unit, description, image, statusservice_order订单表id, order_no, user_id, elderly_id, service_id, appoint_time, address, remark, status, pay_type, create_timeorder_status_log订单状态日志id, order_id, from_status, to_status, operator, create_timehealth_record健康记录表id, elderly_id, type, value, unit, record_timereview评价表id, order_id, user_id, service_level, contentemergency_alert紧急求助记录id, elderly_id, location, alert_time, handle_statusadmin后台管理员表id, username, password, real_name订单号建议用年月日时分秒随机数生成例如20250607153012001避免踩到订单号重复的问题。状态字段用字符串而不是数字状态码可读性更强直接存WAIT_PAY、WAIT_SERVICE、SERVING、FINISHED、CANCELLED写业务逻辑的时候一眼就能看明白。3.3 关键接口实现思路拿“微信登录”这个接口举例。小程序端调用wx.login()拿到临时 code传给后端后端用 code 去微信接口服务换取 openid 和 session_key然后查数据库public class UserController { PostMapping(/login) public Result login(RequestBody LoginRequest req) { // 1. 用 code 调用微信接口 String url https://api.weixin.qq.com/sns/jscode2session; // 2. 获取 openid String openid getOpenid(req.getCode()); // 3. 查询用户是否存在 User user userMapper.selectByOpenid(openid); // 4. 不存在则自动注册 if (user null) { user new User(); user.setOpenid(openid); user.setRole(req.getRole()); userMapper.insert(user); } // 5. 生成token返回前端 String token JwtUtil.createToken(user.getId()); return Result.success(token); } }这里要特别注意实际项目中换 openid 需要 appid 和 secret毕设调试时这两个值要从微信公众平台获取。如果没有注册小程序账号也可以用测试号来开发但测试号的 appid 和正式号不一样后面上线要重新配置。“下单接口”要注意事务控制创建订单、扣减库存如果有数量概念、记录日志这几个动作必须在一个事务里避免出现订单创建成功但日志没写入的脏数据。Spring Boot 里直接在 Service 方法上加Transactional即可。健康记录模块相对简单就是一个针对老人维度的增删改查。要注意的是数值单位统一比如血糖用mmol/L、血压用mmHg前端展示的时候不要混用。4. 从零到一的实操实现全流程4.1 开发环境准备工欲善其事必先利其器。做微信小程序之前把下面的环境装好微信开发者工具直接从官网下载稳定版不要用开发版开发版经常有小毛病。JDK 1.8或Java 8/11和 Maven如果做Spring Boot后端这两个是标配。MySQL 5.7 和 Navicat本地建库建表用。Postman/Apifox接口自测用Apifox可以同步接口文档写论文时还能截接口团队视图。一个微信小程序AppID有学生认证的可以免费注册个人小程序个人小程序部分接口权限受限比如订阅消息可用但部分类目受限不过毕设演示场景问题不大。微信开发者工具第一天就要打开不要等到后端写完再调。很多同学习惯先写后端再建库最后才打开小程序编辑器结果第一周就被各种语法和目录问题搞懵。正确顺序是第一天就新建一个小程序项目里面写一个空页面配好后端接口地址先打通一个最基础的“请求后端返回字符串”的链路之后再逐渐填业务。4.2 小程序端关键页面实现示例首页是老人端最重要的页面布局遵循“高频操作靠前”的原则顶部显示老人头像和问候语中间放“紧急求助”大按钮下面排服务分类再往下是推荐服务卡片。pages/ ├── index/index // 首页 ├── service/list // 服务列表 ├── service/detail // 服务详情 ├── order/confirm // 确认下单 ├── order/list // 我的订单 ├── order/detail // 订单详情 ├── health/list // 健康记录 ├── health/edit // 添加记录 ├── user/index // 个人中心 ├── worker/task // 服务人员端任务列表 ├── worker/taskDetail // 服务人员端任务详情 └── login/index // 登录/角色选择以“服务列表页”为例调接口拿数据后在onLoad中请求使用wx.request时要注意小程序要求域名必须是HTTPS本地开发可以在开发者工具里勾选“不校验合法域名”否则真机预览时请求会直接失败。代码大致是这样getServiceList() { wx.request({ url: http://localhost:8080/api/service/list, method: GET, success: (res) { if (res.data.code 200) { this.setData({ serviceList: res.data.data }); } } }); }页面渲染用wx:for循环列表项serviceItem卡片里包含服务名称、价格、单位、简介点击跳转详情页。要注意的是小程序里wx:for一定要加wx:key否则列表更新时容易出现渲染错乱甚至在小程序基础库版本过低时直接在控制台报警告。订单确认页需要传参我的做法是通过wx.navigateTo的 URL 带 idwx.navigateTo({ url: /pages/order/confirm?serviceId serviceId });在订单确认页的onLoad里用options.serviceId接收。参数多的时候建议用encodeURIComponent转一下再拼到URL里否则遇到特殊字符会截断。服务人员端页面设计从简任务列表里展示“待接单”“待服务”“已完成”三个tab接单按钮点击后调用POST /api/order/accept更新订单状态。为避免接口没返回时用户重复点击按钮点击后要立即禁用再在成功回调中跳转或刷新。4.3 后端Spring Boot工程结构参考后端工程目录建议按功能模块分包避免答辩老师翻代码时看到一堆乱糟糟的类。推荐结构src/main/java/com/example/homecare/ ├── controller/ // 控制层 │ ├── UserController.java │ ├── ServiceController.java │ ├── OrderController.java │ └── HealthController.java ├── service/ // 业务层 │ ├── OrderService.java │ ├── HealthService.java ├── mapper/ // 数据访问层 │ ├── UserMapper.java │ ├── OrderMapper.java └── config/ // 配置类 ├── WebConfig.java └── JwtInterceptor.java实体类用MyBatis-Plus的注解做映射例如Data TableName(service_item) public class ServiceItem { TableId(type IdType.AUTO) private Integer id; private Integer categoryId; private String name; private BigDecimal price; private String unit; private String description; private String image; private Integer status; }Mapper接口继承BaseMapperT之后常见的增删改查就不用手写SQL了项目代码量会少很多写论文里的“系统实现”章节时也能留出篇幅描述MyBatis-Plus的使用。小程序端的请求需要携带登录token所以在拦截器里统一校验Header里的token字段没带token或token过期就返回401前端收到401后跳回登录页。这个逻辑务必实现因为答辩老师十有八九会问“你怎么控制用户登录状态”。4.4 小程序端真机预览与发布流程写完代码在开发者工具里模拟器运行没问题之后一定要点“预览”生成二维码用手机真机跑一遍。模拟器里经常不露出真实的问题比如真机上字体太小、按钮点不到手机网络慢导致请求超时真机上wx.getLocation需要用户手动授权开发版小程序过夜会失效需要重新扫码预览真机调试时如果接口请求失败先确认是不是“开发环境域名校验”的问题。开发阶段可以在小程序后台把本地开发者工具的“不校验合法域名”打开但提交体验版之前要把后端部署到有HTTPS证书的服务器并在小程序后台配置request合法域名。毕设答辩前至少留出三天做部署和真机回归不要等到答辩前一晚才临时部署。5. 常见问题排查与答辩避坑技巧5.1 开发中最容易卡住的十个问题我整理了带学生做这类毕设项目时最高频的十个卡点每个都是实际踩过的问题原因解决方案微信登录一直失败用了别人的AppID或没配置请求域名检查appid和secret是否匹配测试号与正式号环境不互通wx.request发不出去没有打开域名校验或URL没有用HTTPS开发者工具勾选“不校验合法域名”正式版必须用HTTPSsetData后页面不更新数据嵌套太深或没利用this指向使用this.setData({ array[0].name: xxx })正确更新路径数据库中文乱码表和库字符集不是utf8mb4建库语句加DEFAULT CHARSETutf8mb4订单状态串了多方同时更新订单状态状态更新SQL增加WHERE status 当前状态的乐观锁条件Mapper方法找不到XML和Mapper接口没绑定检查namespace、接口方法名和XML里的id是否一一对应时间字段传到前端变成一串数字JSON序列化把Date转成了时间戳在字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)订阅消息推不出去用户没授权或模板ID填错引导用户多次点击授权检查模板ID是否在公众平台申请后端接口明明对了小程序报404路径少写了/多写了斜杠统一用Postman先调通接口再写小程序代码部署到云服务器后连不上数据库安全组没开3306端口在云控制台安全组规则入方向放行MySQL端口5.2 答辩老师常问的问题怎么回答答辩环节最考验的不是代码能力而是对系统的整体把握。根据经验老师高频会问以下几个问题“你的系统角色权限是怎么控制的”回答思路前端通过登录接口传入角色标识user表role字段后端使用JWT拦截器解析token中的userId再查询用户角色接口层面用拦截器或注解校验角色比如带RequireRole(WORKER)注解的管理员接口只能服务人员访问。到这里如果老师听得起劲还可以加一句小程序端角色切换时重新登录获取不同角色的token避免前端伪造。“订单的状态流转是怎么设计的”回答思路在service_order表里维护status字段状态值包括待支付、待服务、服务中、已完成、已取消。状态更新不允许跨级跳转比如待支付不能直接变成已完成所以设计了一张order_status_log表记录每一次状态变更。这个回答既说明了业务逻辑又合理引出了你的表设计是有深意的。“你的系统相比线下传统方式有什么优势”回答思路不要泛泛地说“方便、快捷”要给出具体场景比如子女在外地工作可以通过小程序查看父母健康数据和服务记录老人遇到突发情况可以一键SOS系统自动通知紧急联系人服务过程全留痕平台可以追溯服务质量。三个点覆盖了社会需求、技术实现、平台价值三个维度。“如果用户量变大你的系统哪里最容易成为瓶颈”回答思路这个问题的考察点是看你对系统架构有没有思考。可以从三点回答一是MySQL单库单表数据量大后需要分库分表或引入读写分离二是扫码登录和请求认证每次都查数据库可引入Redis做会话缓存三是服务图片等静态资源如果放在本地服务器带宽会吃紧未来要接对象存储和CDN。即使这些功能没实现也要说得出方案。5.3 提升整个项目档次的几个补充招数毕设想拿高分不需要把功能做得非常多但一定要有几个“让老师觉得你动了脑子”的点。第一招在服务完成时让用户评价评价数据回传后反向影响服务项目的排序。比如评分高的服务项目在列表页靠前这个逻辑用一条SQL就能实现但体现了“数据驱动运营”的思维。第二招给健康记录加“异常提醒”。让家属端设置血压/血糖的报警阈值当新增记录超过阈值时健康模块自动给家属推送订阅消息。这个功能不复杂但论述价值很高论文“系统特色”章节可以大书特书答辩开场白也用得上。第三招接一个简单的数据统计接口。管理后台展示今日订单量、待服务订单数、服务完成率等指标哪怕只是从订单表里SELECT COUNT(*)汇总出来的也会让导师觉得系统有“平台管理”的概念而不是简单的增删改查。第四招在代码里多写注释和日志。给核心Service类和状态流转方法写上清晰注释在业务关键节点打印日志如订单创建、接单、完成答辩前把日志打印放在明显的位置演示时现场展示日志输出效果比你讲十页PPT都好。5.4 论文LW文档怎么写不被老师挑毛病毕业设计文档是这个项目的一半很多同学重代码轻文档结果代码能跑但论文被导师打回去改了三轮。这里分享一条清晰的文档主线绪论写背景、国内外现状、研究内容。背景重点写老龄化趋势和社区养老政策的推进但别大段堆政策原文一两句带过即可重点放在“信息不对称、服务响应慢、子女远程关怀缺失”这几个痛点上。相关技术介绍微信小程序框架、Spring Boot、MySQL、MyBatis-Plus每项写300字左右不要写成百度百科全文复制要写“用在项目的哪个环节”。需求分析画用例图和角色图把P0功能写成结构化用例表格用例名称、参与者、触发条件、主流程、异常流。系统设计架构图、功能模块图、数据库ER图、核心表结构。这里要贴完整的建表SQL至少贴6到8张表的SQL。系统实现每个核心功能配一张页面截图 一段核心代码 两三句实现说明。注意代码不是越多越好截取关键片段并加注释。系统测试写功能测试用例列表和测试结论不要写“系统运行良好”要写“通过XX个核心用例、XX个边界测试整体满足需求”。论文和源代码打包时注意目录结构要清晰doc/放开题报告、论文、答辩PPTcode/放后端工程和前端工程sql/放初始化脚本images/放截图和数据库设计图。一个整理干净的交付包在导师那里的第一印象分差距很大。写在最后从头到尾带完一个居家养老小程序项目我最大的体会是毕业设计不是要把系统做到商业级而是要证明你“具备独立完成一个完整项目的能力”。所以永远把重心放在主流程闭环上像微信登录、下单、状态流转、消息通知这几个核心链路每一个环节都要能讲清楚“为什么这么设计”远比堆砌十几个半成品功能有用得多。最后分享一个关于写代码节奏的小技巧每天开始写代码前花10分钟把当天要完成的接口、页面、数据表变动写在项目根目录的DEV_NOTES.md里哪怕只有五行。坚持到答辩前这份笔记就是你整理论文第五章“系统实现”和答辩论述的最佳素材讲起自己做过什么时底气完全不同。如果你正在找类似选题或者已经做到一半被某个功能卡住希望这篇梳理能帮你把思路理顺。照着这个骨架去搭项目能跑、论文能写、答辩能讲就够用了。剩下的细节遇到具体问题了再逐一击破。