微信小程序+SSM社区养老服务系统毕设完整链路与避坑指南

简介：一份基于微信小程序与SSM框架的社区养老服务系统毕业设计资料包，面向计算机相关专业毕业生、课程设计学生及微信小程序/Java后端学习者。整套方案兼顾代码实践与文档规范，既可用于毕业答辩，也可作为快速入手的完整参考项目。包内共1709个文件，约88.43MB，核心代码以Java、Vue、JavaScript为主，并包含微信小程序前端WXML/WXSS页面、JSON配置、SQL数据库脚本，以及论文、答辩PPT、开题报告、任务书等文档材料，目录结构清晰，便于按需检索与研读。目前已有63人学习使用，适合需要在SSM框架下快速搭建社区服务场景并完成论文撰写的人群。项目源码经过验证可直接运行，同时提供清晰的功能模块划分，读者可以在此基础上替换业务逻辑或补充新功能，省去从零搭建的重复工作。

1. 这个毕业设计资源包里，真正能复现的是一条完整链路

每年这个时候，都会有一批人被毕业设计卡住：题目是“基于微信小程序的社区养老服务系统”，打开学校给的模板却只有零散截图，前端小程序、后端 SSM、论文三块互相接不上，答辩前一周还在补数据。这套资源包的价值在于它把一条完整链路交到你手里——小程序端负责老人或家属下单、志愿者或管理员接单，SSM 后端负责用户、服务项目、预约订单、健康档案的存储和接口，论文和答辩 PPT 则把系统讲成一套能自圆其说的故事。对我这种常年接手二手项目的人，打开压缩包第一件事不是看论文，而是先确认三件事：代码能不能跑、接口通不通、数据库脚本全不全。这套包在这三件事上都做足了准备，适合拿来做毕设底子，也适合想快速理解“小程序 + SSM”前后端协作模式的开发者。

2. 微信小程序端：从登录态到服务预约的请求闭环

小程序端是整个系统的门面，也是答辩时最容易出彩的部分。社区养老服务这类场景，用户群体主要是老年人和他们的子女，所以界面逻辑必须足够简单：打开就是服务列表，点进去能预约，个人中心能看到订单状态。这套小程序端的页面结构是标准的 tabBar 四页——首页、服务、订单、我的，业务上对应浏览、下单、跟踪、个人信息维护，这个划分很稳，几乎没有多余设计。

2.1 登录态与 wx.login 的本地模拟方案

微信小程序的登录不能直接拿 wx.login 的 code 去换用户信息，code 只是临时凭证，必须发给后端，由后端调微信的 code2Session 接口换取 openid。但在毕设环境里，经常出现没有真实 AppID、或者不想配服务器域名的情况，这时候最省事的做法是在后端留一个 mock 登录接口。

// 小程序端 utils/request.js 公共请求封装 const BASE_URL = 'http://localhost:8080/community-care'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method: method, data: data, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else if (res.statusCode === 401) { wx.redirectTo({ url: '/pages/login/login' }); } else { reject(res); } }, fail: (err) => reject(err) }); }); } module.exports = { request };

这段封装是所有页面请求的公共入口。BASE_URL 直接指向本地 Tomcat 端口，方便开发期调试；header 里统一带 token，后端通过拦截器判断登录态。statusCode 401 的兜底跳转是我后来补的，否则 token 过期后用户会一直停留在报错页，体验很差。

对应地，后端提供一个模拟登录：

@RestController @RequestMapping("/api/user") public class UserController { @PostMapping("/login") public Result login(@RequestBody Map<String, String> params) { String code = params.get("code"); // 开发环境直接放行，分配一个测试用户 User user = userService.findByOpenid("mock-openid"); if (user == null) { user = new User(); user.setOpenid("mock-openid"); user.setNickname("测试老人"); userService.register(user); } String token = JwtUtil.createToken(user.getId()); return Result.success(token); } }

开发期省掉 code2Session 调用，用固定 openid 顶替，整套登录链路就能通。切换生产环境时只需要把 mock-openid 换成真实的 code2Session 返回值，其余逻辑原样保留。这个「先本地跑通、再切真实鉴权」的思路，在毕设答辩演示时能省掉大量 Wi-Fi 网络问题。

2.2 首页服务列表的「加载更多」与分页请求

首页的服务列表是访问量最大的接口，如果一次性拉全量数据，数据量大时小程序端会卡顿，所以必须做分页。这里用了传统且稳定的 page 和 size 两个参数，接口返回 total 让前端知道什么时候到底。很多初学者在这一块会犯一个错：直接把 list 字段赋给页面数据，结果第二次请求把第一页数据覆盖了。正确做法是拼接。

// pages/index/index.js 首页服务列表分段加载 Page({ data: { serviceList: [], page: 1, size: 6, hasMore: true, loading: false }, onLoad() { this.loadServices(); }, loadServices() { if (!this.data.hasMore || this.data.loading) return; this.setData({ loading: true }); const { page, size } = this.data; request(`/api/service/list?page=${page}&size=${size}`) .then((res) => { const list = res.data.list || []; this.setData({ serviceList: this.data.serviceList.concat(list), page: page + 1, hasMore: list.length === size, loading: false }); }) .catch(() => this.setData({ loading: false })); }, onReachBottom() { this.loadServices(); } });

onReachBottom 是小程序原生的触底事件，只要页面滚动到底部就会触发。hasMore 的判断逻辑是 list.length === size，如果这次返回的数量不足 size，就认为没有更多了。这个判断有一个边界场景要留意：恰好最后一页数据量等于 size 时，会多触发一次空请求，但返回空数组后 concat 不会有副作用，代价可接受。页面骨架用 wx:for 渲染，列表项点击后跳转详情页，这属于常规写法，没什么玄学。

2.3 服务预约表单与单选框的提交细节

服务预约页是核心转化页面。老人下单时需要选择服务类型、预约日期、上门地址、备注信息。这里最容易踩坑的是「单选框的值没有绑定到正确字段」。小程序端的 radio-group 的 bindchange 事件里，e.detail.value 是字符串而不是对象，如果服务类型的 value 是数字 ID，必须手动转一下类型。

<!-- 预约页面片段 --> <view class="form-group"> <text class="label">选择服务类型</text> <radio-group bindchange="onTypeChange"> <label wx:for="{{serviceTypes}}" wx:key="id"> <radio value="{{item.id}}" checked="{{item.id === form.typeId}}" /> <text>{{item.name}}</text> </label> </radio-group> </view> <view class="form-group"> <text class="label">预约日期</text> <picker mode="date" bindchange="onDateChange" value="{{form.appointDate}}"> <view class="picker">{{form.appointDate || '请选择日期'}}</view> </picker> </view>

对应的事件处理：

onTypeChange(e) { this.setData({ 'form.typeId': Number(e.detail.value) // 显式转数值 }); }, onDateChange(e) { this.setData({ 'form.appointDate': e.detail.value }); }, submitOrder() { const form = this.data.form; if (!form.typeId || !form.appointDate || !form.address) { wx.showToast({ title: '请补全必填项', icon: 'none' }); return; } request('/api/order/create', 'POST', form) .then(() => { wx.showToast({ title: '预约成功', icon: 'success' }); setTimeout(() => wx.switchTab({ url: '/pages/order/order' }), 1500); }) .catch(() => { wx.showToast({ title: '提交失败，请重试', icon: 'none' }); }); }

Number(e.detail.value) 这行是关键。radio 的 value 是字符串，而后端 order 表的 type_id 是 int，不转的话 MyBatis 参数映射会报类型不匹配。另外 submit 前的必填校验一定要做在前端，后端也要再做一次，双保险。这里顺带提一句，日期选择用 picker mode="date" 比手写日历组件稳定得多，毕设场景不需要炫技。

3. SSM 后端：Controller、Service、MyBatis 三层的职责拆解

这套系统的后端是标准 SSM 三件套：Spring 管 Bean、Spring MVC 管接口路由、MyBatis 管数据库操作。很多初学者拿到源码后第一件事是想把所有代码看一遍，这很低效。正确顺序是：先看数据库表结构，再看 MyBatis 的 mapper XML，最后看 Controller 的接口列表。数据库表能告诉你系统有哪些业务实体，mapper 能告诉你数据怎么流动，Controller 则告诉你前端能调什么。

3.1 SSM 常用注解在业务代码里的实际映射

SSM 项目的注解比 Spring Boot 繁琐，但搞清楚了反而更利于理解 Web 应用的运行机制。以服务项目管理的代码为例，看一套最典型的注解组合：

@Controller @RequestMapping("/api/service") public class ServiceItemController { @Autowired private ServiceItemService serviceItemService; @RequestMapping(value = "/list", method = RequestMethod.GET) @ResponseBody public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "6") Integer size) { PageInfo<ServiceItem> pageInfo = serviceItemService.queryPage(page, size); return Result.success(pageInfo); } @RequestMapping(value = "/detail/{id}", method = RequestMethod.GET) @ResponseBody public Result detail(@PathVariable("id") Integer id) { ServiceItem item = serviceItemService.queryById(id); return Result.success(item); } @RequestMapping(value = "/save", method = RequestMethod.POST) @ResponseBody public Result save(@RequestBody ServiceItem item) { serviceItemService.saveOrUpdate(item); return Result.success(null); } }

这套注解组合是 SSM 项目的标准范式。@Controller 加上 @ResponseBody 相当于 @RestController，但很多老项目喜欢拆开写，意思完全一样。@RequestParam 负责接收 query string 参数，并给了默认值，这样前端不传 page 和 size 也不会报错。@PathVariable 接收路径参数，用于/detail/3这类 REST 风格 URL。@RequestBody 把前端传来的 JSON 自动反序列化成 ServiceItem 对象。@Autowired 是字段注入，虽然现在 Spring 官方更推荐构造器注入，但毕设项目的既有代码风格没必要强行改。

有个细节值得注意：@RequestMapping 的 value 路径不要以斜杠结尾，否则某些 Tomcat 版本下会出现 404。这是踩过坑的地方，后面避坑章节会再提。

3.2 Service 层的事务与业务校验

Service 层在 SSM 架构里是业务逻辑的真正落点。以创建预约订单为例，这个操作涉及三步：校验服务项状态、插入订单记录、扣减服务名额或标记接单状态。这三步必须在一个事务里，中途任何一步失败都要回滚。

@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private ServiceItemMapper serviceItemMapper; @Override @Transactional(rollbackFor = Exception.class) public Integer createOrder(Order order) { // 1. 校验服务项存在且可预约 ServiceItem item = serviceItemMapper.selectById(order.getServiceId()); if (item == null || item.getStatus() != 1) { throw new BizException("该服务暂不可预约"); } // 2. 生成订单号，规则：时间戳 + 随机数 String orderNo = "SC" + System.currentTimeMillis() + (int)((Math.random() * 9 + 1) * 1000); order.setOrderNo(orderNo); order.setStatus(0); // 0待接单 1已接单 2已完成 3已取消 order.setCreateTime(new Date()); // 3. 插入订单 orderMapper.insert(order); // 4. 服务项接单数 +1，这里模拟库存扣减 serviceItemMapper.increaseOrderCount(order.getServiceId()); return order.getId(); } }

@Transactional 注解里 rollbackFor = Exception.class 必须写。Spring 默认只在 RuntimeException 时回滚，如果业务代码抛出的是自定义 BizException，而且这个异常继承的是 Exception 而不是 RuntimeException，不加 rollbackFor 就会导致数据库写一半、另外一半没写进去，数据不一致，这在答辩时被老师追问就麻烦了。

3.3 MyBatis 动态 SQL 与模糊查询写法

MyBatis 是这个系统里 SQL 和 Java 的桥梁。管理员后台需要按服务名称、状态、分类做组合筛选，这就要求 mapper XML 里写动态 SQL。最常见的是用 if 标签拼接 where 条件。

<!-- ServiceItemMapper.xml --> <select id="queryByCondition" resultType="com.example.entity.ServiceItem"> SELECT id, name, category, price, unit, status, order_count FROM service_item <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="category != null and category != ''"> AND category = #{category} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY id DESC LIMIT #{offset}, #{pageSize} </select>

where 标签会自动去掉第一个多余的 AND，这是 MyBatis 非常有用的特性。模糊查询用 CONCAT('%', #{name}, '%') 而不是直接写 '%${name}%'，后者有 SQL 注入风险，前者是预编译占位符，安全且是面试官爱问的点。LIMIT #{offset}, #{pageSize} 是 MySQL 分页语法，offset 的计算在 Java 层完成：(page - 1) * pageSize。

如果需要连表查询，比如订单列表要展示服务名称和老人姓名，可以加 JOIN：

<select id="selectOrderDetail" resultType="com.example.dto.OrderVO"> SELECT o.id, o.order_no, o.appoint_date, o.address, o.status, s.name AS service_name, u.nickname AS user_name FROM `order` o LEFT JOIN service_item s ON o.service_id = s.id LEFT JOIN user u ON o.user_id = u.id WHERE o.id = #{id} </select>

order 是 MySQL 关键字，必须用反引号包起来，这是很多新手第一次跑通数据库时卡住的原因。OrderVO 是自定义的视图对象，专门承接连表查询的返回结果，在 Java 里新建一个 DTO 类，字段对应 AS 后的别名，MyBatis 会自动映射。

4. 环境与联调：把微信登录和本地接口跑通的三个关键点

资源包里的代码不管多完整，环境搭不起来就是一堆文件夹。这一章按「数据库初始化 → 后端启动 → 小程序联调」的顺序讲，每一步给出确定性的验证方法。这个顺序不要乱，数据库不对后面全白搭。

4.1 数据库初始化的标准操作

解压后的 sql 目录下通常有 init.sql 或 community_care.sql，里面包含建库建表和初始数据。用 Navicat 或命令行导入都可以，但字符集和排序规则容易出错。

# 命令行导入（MySQL 5.7 及以上） mysql -uroot -p123456 < init.sql # 导入后验证核心表 mysql -uroot -p123456 -e "USE community_care; SHOW TABLES;"

正常情况下会看到 user、service_item、order、category、health_record 等核心表。如果 SHOW TABLES 输出为空，多半是 SQL 文件里没有 USE 语句，导入到了默认库。解决方式是在 SQL 文件最前面补一行USE community_care;，或者导入命令改成：

mysql -uroot -p123456 community_care < init.sql

数据库连接配置在 jdbc.properties 里统一改，不要到处乱写。核心三行配置是 driver、url、账号密码。这里要特别注意 MySQL 8 和 5.7 的驱动差异：

如果你的本地是 MySQL 8，而代码里用的是 5.7 驱动，启动时必报Loading class com.mysql.jdbc.Driver错误，或者Public Key Retrieval is not allowed。前者改成 com.mysql.cj.jdbc.Driver 就行，后者在 url 后面加allowPublicKeyRetrieval=true。

4.2 Tomcat 部署与 IDEA 启动参数

这套代码基于 SSM，用 IDEA 启动时不是直接右键 main 方法，而是配置 Tomcat。常见做法是：用 IDEA 的 Smart Tomcat 插件，或者手动添加 Tomcat Server 配置。但更省心的方式是打包成 war 扔进 Tomcat 的 webapps 目录，console 输出 log 直接决定你能不能跑起来。

一个重要参数是 JDK 版本。很多毕设项目基于 JDK 8 编写，如果你本机是 JDK 11 或 17，可能出现编译错误或注解处理问题。遇到这种情况不要改代码，直接把项目的 SDK 切到 1.8，并确认 pom.xml 里 maven-compiler-plugin 的 source 和 target 都是 1.8。切完之后 Maven 重新 reload，再启动。

启动成功后验证后端是否正常，直接在浏览器访问接口地址：

http://localhost:8080/community-care/api/service/list?page=1&size=6

注意 context-path。如果 war 包名是 community-care.war，那上下文路径就是 /community-care，访问地址必须带上，否则 404。这也是联调时最容易忽略的：小程序端 BASE_URL 忘了带 context-path，导致所有接口全部失败。这类问题在浏览器地址栏里一试便知，不要只在小程序开发者工具里干瞪眼。

4.3 微信开发者工具的真机预览与域名白名单

小程序开发者工具里默认勾选了「不校验合法域名」，本地联调时接口能通。真机预览时如果关了「开发调试」模式，所有 HTTP 请求都会被微信拦截，必须在公众平台配置 request 合法域名，且必须是 HTTPS。毕设阶段没有域名，就保持开发调试模式开着演示，这个细节答辩前一定要提醒自己检查。

另外还有两个高频问题：顶部导航栏高度和底部安全区。不同机型的状态栏高度不同，用 wx.getSystemInfoSync() 里的 statusBarHeight 动态计算，不要写死。

const systemInfo = wx.getSystemInfoSync(); this.setData({ statusBarHeight: systemInfo.statusBarHeight, navBarHeight: systemInfo.statusBarHeight + 44 });

这个 44 是胶囊按钮的高度加上下间距的经验值。写死的话，iPhone 14 和安卓机型的视觉效果会有明显偏差，答辩时老师如果用自己的手机扫演示码，一眼就能看出适配没做。

5. 避坑排查：一次答辩前翻车引出的五条血泪记录

这套系统我帮人排过不少问题，其中五条属于高发，每一条都是真实改过的 bug。按照「现象 → 原因 → 解决」的结构整理在这，遇到相似问题直接对照排查。

5.1 后端接口在浏览器能访问，小程序里全部失败

现象：浏览器输入http://localhost:8080/community-care/api/service/list能返回 JSON，但小程序开发者工具里 request 全部报 fail，Network 显示请求未发出。

原因：小程序开发者工具默认开启了「不校验合法域名」，但如果你把本地请求地址写成了http://127.0.0.1:8080或者带端口访问，且项目设置里的「模拟器」环境发生了变化，请求会被网络层拦截。还有一种可能是 BASE_URL 末尾带了斜杠，导致路径拼接出现双斜杠，部分服务器会直接拒绝。

解决：确认 BASE_URL 是http://localhost:8080/community-care，路径不要以斜杠结尾；在开发者工具详情里勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。还是不行就用wx.request的完整 url 打日志，别猜。

5.2 MyBatis 插入订单成功但主键没有回填

现象：orderMapper.insert(order)执行后，数据库表里确实新增了一条记录，但order.getId()返回的是 null，后面的逻辑拿不到订单 ID。

原因：Mapper XML 的 insert 语句里没有配置 useGeneratedKeys 和 keyProperty。MyBatis 默认不会把数据库自增主键回填到实体对象里。

解决：

<insert id="insert" parameterType="com.example.entity.Order" useGeneratedKeys="true" keyProperty="id"> INSERT INTO `order` (order_no, user_id, service_id, appoint_date, address, status) VALUES (#{orderNo}, #{userId}, #{serviceId}, #{appointDate}, #{address}, #{status}) </insert>

useGeneratedKeys="true" 告诉 MyBatis 使用 JDBC 的 getGeneratedKeys 方法，keyProperty="id" 指定回填到实体的哪个属性。加完这两句，insert 之后实体里的 id 就有值了。

5.3 微信小程序页面列表渲染正常，但下拉刷新后白屏

现象：首次进入首页能看到服务列表，下拉刷新后页面变成空白，控制台报Cannot read property 'length' of undefined。

原因：刷新回调里把page重置为 1 的同时，没有清空已有的 serviceList。第二次 request 返回后执行 concat，本来没问题，但如果接口返回的数据结构里list字段不存在，取res.data.list时就是 undefined，然后访问list.length直接崩。

解决： onPullDownRefresh 里先 setData 清空列表，再重置分页参数：

onPullDownRefresh() { this.setData({ serviceList: [], page: 1, hasMore: true }); this.loadServices(() => wx.stopPullDownRefresh()); }

把成功回调里对res.data.list的读取加一层兜底：

const list = (res.data && res.data.list) || [];

这种防御式写法在接口联调阶段特别有用，后端还没写好时前端不会直接崩。

5.4 预约日期显示前一天或相差 8 小时

现象：用户在预约页选择 2025-03-20，提交后管理端看到的日期是 2025-03-19 或 2025-03-20 但时间变成 08:00 开头。

原因：时区问题。小程序端 picker 返回的是YYYY-MM-DD字符串，但后端用new Date()解析时，如果 JVM 时区是 GMT，会把日期解析成 UTC 时间，然后再转换为东八区就会偏移。另一个场景是 MySQL 连接 url 里的 serverTimezone 没配，数据库会话时区和 JVM 时区不一致。

解决：url 上加serverTimezone=Asia/Shanghai，JVM 启动参数加-Duser.timezone=GMT+8。后端接收日期字段时不要用 Date 类型接收字符串，直接用 String 接收再格式化，避免转换层出乱子。推荐用@DateTimeFormat(pattern = "yyyy-MM-dd")配合 String 字段，存库前再转 Date，逻辑清晰可控。

5.5 答辩 PPT 里的系统架构图和实际代码对不上

现象：PPT 里画的是前后端分离架构，但代码里 Controller 直接返回 ModelAndView；或者 PPT 说用了 Redis 缓存，代码里根本没引入。

原因：资源包里的 PPT 和源码来自同一个项目模版，但有时候论文是从别的项目拼的，架构图不是这套代码的。答辩时老师一眼看出图与实不符，这是最痛的一种翻车。

解决：拿到包后对照三样东西——数据库表、Controller 的 RequestMapping、前端页面，把 PPT 里的架构图改成实际项目的模样。一般只需改模块名和箭头流向。另外把「技术亮点」里不涉及的中间件全部删掉，只留代码里真正出现的，否则回答不上来。

6. 验证技巧：用一份接口自检清单验收整套系统

系统跑通只是第一步，答辩前能稳定演示是另一回事。我有一套自检习惯，在最终交付前按顺序过一遍所有核心链路，每个环节都有明确验证方式。这一章把这条验证链路完整写出来，你照着走一遍，比盲目点页面发现 bug 再修效率高得多。

先看数据库层面的自检。打开 MySQL 命令行，执行几条关键查询，确认基础数据已经初始化：

SELECT COUNT(*) FROM user; -- 期望有测试账号数据 SELECT COUNT(*) FROM service_item; -- 期望有 6-10 条服务项 SELECT COUNT(*) FROM `order`; -- 期望有至少 2 条不同状态的订单

如果 order 表是空的，演示时「订单管理」页面就会空荡荡。解决方案是手动往库里插几条不同状态的数据，包括待接单、已完成、已取消，这样管理员端的状态筛选才能展示出效果。

然后是接口链路。按照业务流程顺序，一个接口一个接口验证，我自己总结的表格长这样：

创建预约订单这条链路最关键，它同时涉及两个表：order 表新增记录，service_item 表的 order_count 加 1。验证方法先记录接单前 order_count 的值，创建订单后再查一次，确认加了 1。如果没有变化，说明 Service 层事务里有一步失效了，回到 3.2 章节去检查事务配置。

前端页面验证同样有固定套路。我习惯在每个 tabBar 页面上放一个 console.log，打印关键数据加载的结果。比如首页 onLoad 成功后打印this.data.serviceList.length，下拉刷新后打印重置后的第一条记录，这样滚动加载报错时能快速定位是数据问题还是渲染问题。

最后一个技巧是关于答辩演示顺序的优化。不要打开系统就从头点一遍，而是设计一个完整故事：某老人需要助餐服务 → 打开小程序浏览服务列表 → 筛选出助餐服务 → 下单填写地址和时间 → 管理员端看到新订单 → 接单 → 老人端订单状态变为「已接单」→ 服务完成 → 评价。照着这条故事线走，所有核心页面和状态流转都会展示到，而且不会因为「临时找一个可用的服务项」浪费答辩时间。

从那以后我每次拿到一套不熟悉的毕设源码，都强制自己先走一遍接口自检清单，再碰页面。这套验证习惯帮我避免过太多次“演示时现场翻车”的尴尬局面，也让我对代码里每个模块的实际行为有底，而不是只在答辩时靠背稿支撑。这套资源包里该有的代码、论文、PPT 都齐了，你拿到手之后第一件事不是看代码，而是建库、启动、按清单走一遍链路，先让它跑起来，再去读实现。开头你可能会遇到一两个 bug，那就是这份资源给你出的第一道题——能解决它，你就真正开始拥有这套系统了。希望帮到你。

本文还有配套的精品资源，点击获取