简介面向计算机相关专业学生的本科毕业设计论文《基于微信小程序的小区管理系统设计与实现》围绕小区物业管理信息化与移动端实时互动问题展开。系统设有管理员与用户两种角色管理员涵盖个人中心、用户管理、投诉建议、房屋信息、故障维修、公告、入住登记及轮播图等模块用户可注册登录、查看房屋与公告、提交维修和投诉建议。技术实现采用Java开发网站后台通过JSON与微信小程序端交互并使用MySQL数据存储论文中归纳了微信小程序应用优势、Java与MySQL在系统中的作用、移动互联网时代物业管理发展趋势等关键知识点。资源包共含1个doc文档大小1.27MB已有116人学习适合毕业设计选题相近或需要参考系统设计、论文写作规范的读者。1. 为什么小区物业系统选择微信小程序加 SSM 加 MySQL移动互联网把用户习惯彻底改了看公告、报修、交投诉业主希望打开微信就能做完而不是再装一个 App。基于微信小程序的小区管理系统正是从这个场景切入用户端跑在微信里管理端用 SSMSpring SpringMVC MyBatis提供 JSON 接口MySQL 承担数据存储。小程序端只做展示和表单采集业务判定和事务放后台 Service 层数据库表按业务拆开不搞大而全的单表设计。整套方案在开发成本、维护难度、运行稳定性之间比较平衡适合本科毕设、课程设计也适合小体量物业团队做信息化试点。2. 数据库表结构与权限模型设计要点系统里只有两类角色管理员和业主。管理员管用户、管房屋、管公告、回维修单、回投诉、维护基础数据和轮播图业主注册登录后查房屋、看公告、提交报修和投诉建议、办理入住登记。梳理链路时我坚持一个原则管理员不直接改业务表里的归属字段业主信息单独放 yonghu 表业务表统一用 yonghu_id 关联业主。这样无论是输出业主的报修历史还是后台按用户维度统计一条 SQL 就能解决不会出现同一份数据散落在多个表里的情况。2.1 先梳理核心业务链路先看业主这条链路注册登录 → 查看公告 → 查看房屋 → 提交故障维修单 → 提交投诉建议 → 入住登记。管理员这条链路用户管理 → 房屋信息管理 → 公告管理 → 维修单处理 → 投诉建议回复 → 轮播图管理。两条链路的交叉点是 yonghu 表和这几张业务表的外键字段所以每张业务表都保留 yonghu_id 作为归属标识。这里有一个很常见的错误做法让业务表自己存用户名而不是存用户 id。用户名是可变信息业主改名后历史维修单里的名字会全部失效存 id 配合 JOIN 查最新用户名才是稳固的做法。另一个容易忽略的点是管理员操作要落在基础数据表上比如房屋类型、维修类型、公告类型都要放在字典表里而不是散落在页面下拉框的写死列表中。2.2 MySQL 建表脚本MySQL 选 5.7 或 8.0 都行存储引擎 InnoDB字符集 utf8mb4。这个项目数据量不大但 MySQL 官方支持千万条级别的表毕设或者物业信息化试点完全够用。下面是我按这套业务整理的建表脚本注释里标明了字段含义。CREATE DATABASE IF NOT EXISTS community DEFAULT CHARACTER SET utf8mb4; USE community; CREATE TABLE yonghu ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 业主 id, username VARCHAR(30) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT 密码哈希BCrypt, name VARCHAR(30) COMMENT 真实姓名, phone VARCHAR(20) COMMENT 联系电话, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间 ) ENGINEInnoDB COMMENT业主表; CREATE TABLE fangwuxinxi ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 房屋 id, fangwuxinxi_name VARCHAR(50) NOT NULL COMMENT 房屋名称, fangwuxinxi_photo VARCHAR(200) COMMENT 房屋图片, fangwuxinxi_types INT COMMENT 房屋类型关联字典表, fangwuxinxi_size VARCHAR(10) COMMENT 面积大小, fangwuxinxi_buju VARCHAR(50) COMMENT 户型布局, fangwuxinxi_content TEXT COMMENT 房屋详情, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT房屋信息表; CREATE TABLE guzhangweixiu ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 维修单 id, yonghu_id INT COMMENT 报修业主 id, guzhang_name VARCHAR(50) NOT NULL COMMENT 故障标题, guzhang_types INT COMMENT 故障类型关联字典表, guzhang_photo VARCHAR(200) COMMENT 故障图片, guzhang_content TEXT COMMENT 故障描述, zhuangtai_types TINYINT DEFAULT 1 COMMENT 1待处理 2处理中 3已完成, insert_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 提交时间 ) ENGINEInnoDB COMMENT故障维修表; CREATE TABLE tousujianyi ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 投诉建议 id, yonghu_id INT COMMENT 提交用户 id, chat_issue VARCHAR(500) COMMENT 问题描述, issue_time DATETIME COMMENT 问题时间, chat_reply VARCHAR(500) COMMENT 管理员回复, reply_time DATETIME COMMENT 回复时间, zhuangtai_types TINYINT DEFAULT 1 COMMENT 1未回复 2已回复, chat_types TINYINT COMMENT 1投诉 2建议, insert_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT投诉建议表; CREATE TABLE ruzhudengji ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 入住登记 id, yonghu_id INT COMMENT 业主 id, ruzhudengji_name VARCHAR(100) COMMENT 入住地址, ruzhudengji_photo VARCHAR(200) COMMENT 房屋图片, ruzhudengji_types INT COMMENT 房屋类型, ruzhudengji_shijian VARCHAR(50) COMMENT 入住时间, ruzhudengji_renyuan VARCHAR(200) COMMENT 入住人员, ruzhudengji_content TEXT COMMENT 详情备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT入住登记表;fangwuxinxi_types、guzhang_types、ruzhu..._types都设计成 int只存类型编号类型名由字典表统一解释后台做下拉筛选时不需要改表结构。zhuangtai_types用 TINYINT状态递增 1→2→3前端对状态做字典映射即可。所有表都带 create_time 并设置 DEFAULT CURRENT_TIMESTAMP省去手动赋值也方便排查数据产生时间。2.3 为什么用逻辑外键而不是物理外键直接在建表语句里写 FOREIGN KEY 的写法在初期很爽后面调整业务会很难受。比如房屋信息被入住登记和维修单同时引用批量修复数据时物理外键会阻止许多 UPDATE。我一般只建索引不建约束字段有效性由 Service 层保证删除用户前先查有没有关联的维修单、投诉单存在就提示用户不能删除而不是靠数据库抛外键异常。逻辑外键在 SSM 这个场景下还有一个实际好处拆分表、归档历史数据时不需要 DROP 外键。这个系统不追求极端一致性业务上能说明白「谁操作的、关联谁」就够了。但对应列要加索引否则按 yonghu_id 查历史单子会全表扫描。2.4 时间字段与 JDBC 连接串时间字段用 DATETIME 而不是 TIMESTAMP。DATETIME 的存储范围大不受 1970 和 2038 年限制展示时也不会有时区换算的隐式逻辑。最容易翻车的是 JDBC 连接串没有配 serverTimezone后端拿到的时间比北京标准时间少 8 小时。Java 与 MySQL 连接时按下面这个串配置即可jdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai参数说明useUnicode 和 characterEncoding 保证中文不乱码serverTimezone 指定数据库所在时区为东八区解决 Java 8 时间 API 与 MySQL DATETIME 转换产生的偏移。字段层面的注意点讲完表层面的速查关系汇总如下表名用途关键字段类型字段说明yonghu业主信息id, username, password无fangwuxinxi房屋信息fangwuxinxi_name, fangwuxinxi_types1高层 2洋房 3商铺guzhangweixiu故障维修guzhang_types, zhuangtai_types状态流转 1→2→3tousujianyi投诉建议chat_types, zhuangtai_types1投诉 2建议ruzhudengji入住登记yonghu_id, ruzhudengji_name关联房屋类型上面的字典编号只是示例具体序号要和 dictionary 表里的数据保持一致。3. SSM 后台如何接收并校验小程序请求小程序端与后端交互的数据格式是 JSON后端用 Spring MVC 的 RequestBody 直接反序列化成实体对象。SSM 的分层方式比较标准Controller 负责接收和返回Service 负责业务规则Mapper 负责 SQL。这样划分后小程序端无论是查列表还是提交表单走的都是同一套接口规范。3.1 分层结构与事务边界Controller 层尽量保持「薄」只做参数接收、校验结果转换、调用 Service 这三件事。复杂业务逻辑放在 Service 里因为 Controller 里的代码很难做单元测试而 Service 是纯 Java 方法可以脱离 HTTP 容器直接测。事务只加在读改写的方法上比如入住登记、维修单状态流转、投诉回复用 Transactional(rollbackFor Exception.class) 把整个方法包进去。注意不要把事务加在 Controller 上否则一个请求里多个无关操作共享同一个连接和锁并发上来后很容易出现锁等待。这里有一个小细节MyBatis 的 Mapper 接口方法名不要用 insert/update 这类通用单词最好带业务含义比如 insertWeixiuOrder、updateReplyStatus查日志时能快速定位。3.2 统一返回格式接口返回结构如果每个 Controller 都自己拼 Map小程序端解析起来会很混乱。我一般定义一个 Result 类固定 code、msg、data 三个字段。code 为 200 表示成功401 表示 token 失效500 表示业务异常。小程序端在封装 request 时只需判断 code 就能决定是刷新列表还是跳登录页。public class ResultT { private Integer code; private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT error(Integer code, String msg) { ResultT r new Result(); r.code code; r.msg msg; return r; } }参数说明ok 方法的 data 可以是 List、对象或 null分页接口会把 total 同时放进去error 方法用来在全局异常处理器里返回统一错误信息避免小程序端拿到无法解析的异常堆栈。3.3 登录接口与 token 生命周期登录接口接收 username 和 password校验通过后生成一个随机 token更新到 yonghu 表的 token 字段并把 token 返回给小程序端。后续业务接口的请求头都带 token拦截器根据 token 查出 userId 放入 ThreadLocalController 从 ThreadLocal 取当前操作人的 id。PostMapping(/auth/login) public Result login(RequestBody LoginRequest req) { Yonghu user yonghuMapper.selectByUsername(req.getUsername()); if (user null || !passwordEncoder.matches(req.getPassword(), user.getPassword())) { return Result.error(500, 用户名或密码错误); } String token UUID.randomUUID().toString().replace(-, ); yonghuMapper.updateToken(user.getId(), token); return Result.ok(token); }逻辑说明密码比对用 BCrypt数据库里不存明文token 用 UUID 去掉横线后的随机串写入用户表。毕设这个规模用数据库存 token 就够了不需要引入 Redis。后面并发上来了再把存储替换成 Redis 并给 token 加过期时间演进路径是清晰的一开始就堆缓存组件反而增加部署复杂度。3.4 报修单提交接口实现下面给维修单提交的完整实现。重点是 userId 来自拦截器而不是前端表单。RestController RequestMapping(/api/weixiu) public class GuzhangweixiuController { Autowired private GuzhangweixiuService guzhangweixiuService; PostMapping(/add) public Result add(RequestBody Guzhangweixiu weixiu, RequestAttribute(userId) Integer userId) { weixiu.setYonghuId(userId); return Result.ok(guzhangweixiuService.add(weixiu)); } }Service public class GuzhangweixiuService { Autowired private GuzhangweixiuMapper guzhangweixiuMapper; Transactional(rollbackFor Exception.class) public Guzhangweixiu add(Guzhangweixiu weixiu) { if (weixiu.getGuzhangName() null || .equals(weixiu.getGuzhangName())) { throw new BusinessException(500, 故障标题不能为空); } if (weixiu.getGuzhangTypes() null) { throw new BusinessException(500, 请选择故障类型); } weixiu.setZhuangtaiTypes(1); weixiu.setInsertTime(new Date()); guzhangweixiuMapper.insertWeixiuOrder(weixiu); return weixiu; } }逻辑说明Controller 通过 RequestAttribute 拿到拦截器解析出的 userId然后覆盖前端传进来的 yonghuId。这样即使用户在抓包工具里改了 yonghu_id也无法替别人报修。Service 层的校验是最终防线小程序端的校验可以被绕过但 Service 层不会。insertTime 和 zhuangtaiTypes 都在 Service 层赋值前端提交过来的状态值一律忽略。3.5 拦截器与放行路径配置登录校验用 Spring 拦截器做不依赖每段代码重复写判断。preHandle 里从 Header 拿 token查用户表没有或过期就返回 401有就把 userId 塞进 request attribute。public class LoginInterceptor implements HandlerInterceptor { Autowired private YonghuMapper yonghuMapper; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(token); if (token null || .equals(token)) { throw new BusinessException(401, 未登录); } Yonghu yonghu yonghuMapper.selectByToken(token); if (yonghu null) { throw new BusinessException(401, 登录已过期); } request.setAttribute(userId, yonghu.getId()); return true; } }在 WebMvcConfig 里注册拦截器并配置放行路径。下面的规则里登录、首页公告和轮播图、图片静态资源放行其余全部拦截路径处理方式/auth/login放行/api/home/**放行公告、轮播图/upload/**放行图片静态资源/api/**校验 token其他返回 404放行 /api/home/** 是因为未登录业主也能看首页公告和轮播图房屋列表是否放行看产品设计如果房屋信息公开建议也放行只对提交类接口做登录要求。4. 微信小程序端的房屋查询与报修提交实现小程序端按 tabBar 划分四个主页面首页、房屋、报修、我的。每个页面都从后端拉 JSON 数据用 setData 更新视图。整套数据流很简单前端只关心「渲染什么、提交什么」业务规则全部交给后端。4.1 页面路由与数据流首页展示公告列表和轮播图房屋页展示房屋卡片报修页是表单我的页面展示用户信息和我的维修单入口。数据流上列表页在 onShow 里重新拉取数据而不是只在 onLoad 拉一次。业主切换 tab 回到列表页时数据可能已经变化重新请求的成本很低但能避免「看到已过期数据」的体验问题。接口作用请求方式/auth/login业主登录POST/api/fangwu/list房屋列表GET/api/weixiu/add提交报修POST/api/tousu/add提交投诉建议POST/api/ruzhu/add入住登记POST小程序端不直接操作数据库所有请求都走 request 封装函数统一带 token、统一解析返回码。下面是我常用的封装const baseUrl https://api.example.com function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: baseUrl url, method, data, header: { Content-Type: application/json, token: token }, success: (res) { if (res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) return } resolve(res.data) }, fail: (err) reject(err) }) }) } module.exports { request }参数说明token 存在本地 storage每次请求从 storage 读出并放进 header。后端拦截器拿到 token 后识别登录用户当返回 code 为 401 时统一跳登录页业务页面不需要自己处理登录过期。后端接口都返回同样结构的 JSON前端一个 if 就能覆盖所有情况。4.2 房屋列表与类型筛选房屋列表页的数据渲染用 wx:for 完成。每个房屋卡片展示图片、名称、户型、面积和类型名。类型名不要在前端写死后端根据字典表返回的 map 组装好前端直接用。async loadHouses(typeId) { const res await request({ url: /api/fangwu/list, method: GET, data: typeId ? { fangwuxinxiTypes: typeId } : {} }) if (res.code 200) { this.setData({ list: res.data }) } }view classhouse-card wx:for{{list}} wx:keyid image src{{item.fangwuxinxiPhoto}} modeaspectFill classhouse-img/image view classhouse-name{{item.fangwuxinxiName}}/view view classhouse-meta{{item.fangwuxinxiBuju}} · {{item.fangwuxinxiSize}}/view view classhouse-type{{typeMap[item.fangwuxinxiTypes]}}/view /view逻辑说明loadHouses 接收可选的 typeId为空时拉全量列表非空时按类型过滤。typeMap 是后端把字典表转成对象返回的结果类似于{1: 高层, 2: 洋房}前端用数组下标方式拿到类型名页面底部切换类型时重新调用 loadHouses 即可。注意 wx:key 绑定的是每条的 id不要用 index否则列表删除或重排时渲染状态容易错乱。4.3 报修表单提交与图片上传报修页涉及文本和图片两类数据。图片用 wx.chooseMedia 选择用 wx.uploadFile 传回后端后端返回图片地址后再和表单文本一起提交。顺序不要颠倒否则图片地址还没拿到就提交了。async chooseAndUpload() { const res await wx.chooseMedia({ count: 1, mediaType: [image], sourceType: [album, camera] }) const tempPath res.tempFiles[0].tempFilePath const token wx.getStorageSync(token) wx.uploadFile({ url: baseUrl /api/upload, filePath: tempPath, name: file, header: { token: token }, success: (up) { const result JSON.parse(up.data) this.setData({ uploadedUrl: result.data }) } }) }参数说明wx.chooseMedia 的 count 限制单次选择数量这里限制为 1sourceType 允许相册选图和拍照。wx.uploadFile 的上传参数 name 是后端 MultipartFile 的形参名必须和后端接口接收的字段名一致否则文件收不到。后端转存图片后返回相对路径如 /upload/2024/xxx.jpg页面 img 标签拼接 baseUrl 即可访问。4.4 维修单状态轮询业主提交维修单后希望看到后台处理状态。最简单的方式是 onShow 里启动轮询30 秒请求一次我的维修单列表onHide 时清除定时器。onShow() { this.timer setInterval(() this.loadMyOrders(), 30000) }, onHide() { if (this.timer) { clearInterval(this.timer) this.timer null } }说明一定要在 onHide 里清掉定时器否则页面在后台时请求持续发用户会被手机系统提示耗电过多小程序也可能被微信后台杀掉。轮询间隔 30 秒对这个场景足够不需要 WebSocket真机调试时也可以临时改成 3 秒观察数据变化。5. 真机调试与联调中最值得处理的几个细节5.1 开发者工具能通真机却请求失败如果本地请求 http://localhost:8080 正常换到真机预览后请求一直 fail原因通常是合法域名校验。微信小程序要求所有请求域名在「小程序后台-开发管理-服务器域名」中配置并且必须是 https。开发阶段有两个办法一是在开发者工具「详情-本地设置」勾选「不校验合法域名」二是把接口域名改成已经备案的 https 域名。提交审核前所有后端接口和上传接口都要换成 https并且 wx.request、wx.uploadFile 的域名也要保持一致否则真机上依然被拦截。5.2 setData 更新列表的常见误用直接修改 this.data.list[0].name 不会触发页面渲染因为 setData 才是数据到视图的通道。修改数组中的单个元素时推荐用 key 方式this.setData({ [list[ index ].zhuangtaiTypes]: 2 })这个写法利用小程序的数组路径表达式只更新变化的节点避免整段 list 重新渲染。如果更新后需要展示最新列表直接把接口返回的 res.data 赋值给 list 也行但列表超过 50 条时整段替换会造成明显的渲染抖动。5.3 token 失效后重放请求的技巧token 过期后用户正在填的报修表单会丢失体验很差。我一般在 request 封装里拦截 401把当前的 url、method、data 暂存在 globalData.pendingAction 中跳转登录页。登录成功后回到业务页检查 globalData.pendingAction 是否存在存在就重新发起请求。重放前要确认接口是幂等的否则提交类操作会插入两条数据。我的做法是提交接口带一个前端生成的 requestId后端收到请求后先去表里查这个 requestId存在就直接返回旧结果不存在才插入这样即便请求重放多次数据也只有一份。本文还有配套的精品资源点击获取 基于微信小程序与SSM的小区物业管理系统设计与实现
简介面向计算机相关专业学生的本科毕业设计论文《基于微信小程序的小区管理系统设计与实现》围绕小区物业管理信息化与移动端实时互动问题展开。系统设有管理员与用户两种角色管理员涵盖个人中心、用户管理、投诉建议、房屋信息、故障维修、公告、入住登记及轮播图等模块用户可注册登录、查看房屋与公告、提交维修和投诉建议。技术实现采用Java开发网站后台通过JSON与微信小程序端交互并使用MySQL数据存储论文中归纳了微信小程序应用优势、Java与MySQL在系统中的作用、移动互联网时代物业管理发展趋势等关键知识点。资源包共含1个doc文档大小1.27MB已有116人学习适合毕业设计选题相近或需要参考系统设计、论文写作规范的读者。1. 为什么小区物业系统选择微信小程序加 SSM 加 MySQL移动互联网把用户习惯彻底改了看公告、报修、交投诉业主希望打开微信就能做完而不是再装一个 App。基于微信小程序的小区管理系统正是从这个场景切入用户端跑在微信里管理端用 SSMSpring SpringMVC MyBatis提供 JSON 接口MySQL 承担数据存储。小程序端只做展示和表单采集业务判定和事务放后台 Service 层数据库表按业务拆开不搞大而全的单表设计。整套方案在开发成本、维护难度、运行稳定性之间比较平衡适合本科毕设、课程设计也适合小体量物业团队做信息化试点。2. 数据库表结构与权限模型设计要点系统里只有两类角色管理员和业主。管理员管用户、管房屋、管公告、回维修单、回投诉、维护基础数据和轮播图业主注册登录后查房屋、看公告、提交报修和投诉建议、办理入住登记。梳理链路时我坚持一个原则管理员不直接改业务表里的归属字段业主信息单独放 yonghu 表业务表统一用 yonghu_id 关联业主。这样无论是输出业主的报修历史还是后台按用户维度统计一条 SQL 就能解决不会出现同一份数据散落在多个表里的情况。2.1 先梳理核心业务链路先看业主这条链路注册登录 → 查看公告 → 查看房屋 → 提交故障维修单 → 提交投诉建议 → 入住登记。管理员这条链路用户管理 → 房屋信息管理 → 公告管理 → 维修单处理 → 投诉建议回复 → 轮播图管理。两条链路的交叉点是 yonghu 表和这几张业务表的外键字段所以每张业务表都保留 yonghu_id 作为归属标识。这里有一个很常见的错误做法让业务表自己存用户名而不是存用户 id。用户名是可变信息业主改名后历史维修单里的名字会全部失效存 id 配合 JOIN 查最新用户名才是稳固的做法。另一个容易忽略的点是管理员操作要落在基础数据表上比如房屋类型、维修类型、公告类型都要放在字典表里而不是散落在页面下拉框的写死列表中。2.2 MySQL 建表脚本MySQL 选 5.7 或 8.0 都行存储引擎 InnoDB字符集 utf8mb4。这个项目数据量不大但 MySQL 官方支持千万条级别的表毕设或者物业信息化试点完全够用。下面是我按这套业务整理的建表脚本注释里标明了字段含义。CREATE DATABASE IF NOT EXISTS community DEFAULT CHARACTER SET utf8mb4; USE community; CREATE TABLE yonghu ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 业主 id, username VARCHAR(30) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT 密码哈希BCrypt, name VARCHAR(30) COMMENT 真实姓名, phone VARCHAR(20) COMMENT 联系电话, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间 ) ENGINEInnoDB COMMENT业主表; CREATE TABLE fangwuxinxi ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 房屋 id, fangwuxinxi_name VARCHAR(50) NOT NULL COMMENT 房屋名称, fangwuxinxi_photo VARCHAR(200) COMMENT 房屋图片, fangwuxinxi_types INT COMMENT 房屋类型关联字典表, fangwuxinxi_size VARCHAR(10) COMMENT 面积大小, fangwuxinxi_buju VARCHAR(50) COMMENT 户型布局, fangwuxinxi_content TEXT COMMENT 房屋详情, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT房屋信息表; CREATE TABLE guzhangweixiu ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 维修单 id, yonghu_id INT COMMENT 报修业主 id, guzhang_name VARCHAR(50) NOT NULL COMMENT 故障标题, guzhang_types INT COMMENT 故障类型关联字典表, guzhang_photo VARCHAR(200) COMMENT 故障图片, guzhang_content TEXT COMMENT 故障描述, zhuangtai_types TINYINT DEFAULT 1 COMMENT 1待处理 2处理中 3已完成, insert_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 提交时间 ) ENGINEInnoDB COMMENT故障维修表; CREATE TABLE tousujianyi ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 投诉建议 id, yonghu_id INT COMMENT 提交用户 id, chat_issue VARCHAR(500) COMMENT 问题描述, issue_time DATETIME COMMENT 问题时间, chat_reply VARCHAR(500) COMMENT 管理员回复, reply_time DATETIME COMMENT 回复时间, zhuangtai_types TINYINT DEFAULT 1 COMMENT 1未回复 2已回复, chat_types TINYINT COMMENT 1投诉 2建议, insert_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT投诉建议表; CREATE TABLE ruzhudengji ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 入住登记 id, yonghu_id INT COMMENT 业主 id, ruzhudengji_name VARCHAR(100) COMMENT 入住地址, ruzhudengji_photo VARCHAR(200) COMMENT 房屋图片, ruzhudengji_types INT COMMENT 房屋类型, ruzhudengji_shijian VARCHAR(50) COMMENT 入住时间, ruzhudengji_renyuan VARCHAR(200) COMMENT 入住人员, ruzhudengji_content TEXT COMMENT 详情备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB COMMENT入住登记表;fangwuxinxi_types、guzhang_types、ruzhu..._types都设计成 int只存类型编号类型名由字典表统一解释后台做下拉筛选时不需要改表结构。zhuangtai_types用 TINYINT状态递增 1→2→3前端对状态做字典映射即可。所有表都带 create_time 并设置 DEFAULT CURRENT_TIMESTAMP省去手动赋值也方便排查数据产生时间。2.3 为什么用逻辑外键而不是物理外键直接在建表语句里写 FOREIGN KEY 的写法在初期很爽后面调整业务会很难受。比如房屋信息被入住登记和维修单同时引用批量修复数据时物理外键会阻止许多 UPDATE。我一般只建索引不建约束字段有效性由 Service 层保证删除用户前先查有没有关联的维修单、投诉单存在就提示用户不能删除而不是靠数据库抛外键异常。逻辑外键在 SSM 这个场景下还有一个实际好处拆分表、归档历史数据时不需要 DROP 外键。这个系统不追求极端一致性业务上能说明白「谁操作的、关联谁」就够了。但对应列要加索引否则按 yonghu_id 查历史单子会全表扫描。2.4 时间字段与 JDBC 连接串时间字段用 DATETIME 而不是 TIMESTAMP。DATETIME 的存储范围大不受 1970 和 2038 年限制展示时也不会有时区换算的隐式逻辑。最容易翻车的是 JDBC 连接串没有配 serverTimezone后端拿到的时间比北京标准时间少 8 小时。Java 与 MySQL 连接时按下面这个串配置即可jdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai参数说明useUnicode 和 characterEncoding 保证中文不乱码serverTimezone 指定数据库所在时区为东八区解决 Java 8 时间 API 与 MySQL DATETIME 转换产生的偏移。字段层面的注意点讲完表层面的速查关系汇总如下表名用途关键字段类型字段说明yonghu业主信息id, username, password无fangwuxinxi房屋信息fangwuxinxi_name, fangwuxinxi_types1高层 2洋房 3商铺guzhangweixiu故障维修guzhang_types, zhuangtai_types状态流转 1→2→3tousujianyi投诉建议chat_types, zhuangtai_types1投诉 2建议ruzhudengji入住登记yonghu_id, ruzhudengji_name关联房屋类型上面的字典编号只是示例具体序号要和 dictionary 表里的数据保持一致。3. SSM 后台如何接收并校验小程序请求小程序端与后端交互的数据格式是 JSON后端用 Spring MVC 的 RequestBody 直接反序列化成实体对象。SSM 的分层方式比较标准Controller 负责接收和返回Service 负责业务规则Mapper 负责 SQL。这样划分后小程序端无论是查列表还是提交表单走的都是同一套接口规范。3.1 分层结构与事务边界Controller 层尽量保持「薄」只做参数接收、校验结果转换、调用 Service 这三件事。复杂业务逻辑放在 Service 里因为 Controller 里的代码很难做单元测试而 Service 是纯 Java 方法可以脱离 HTTP 容器直接测。事务只加在读改写的方法上比如入住登记、维修单状态流转、投诉回复用 Transactional(rollbackFor Exception.class) 把整个方法包进去。注意不要把事务加在 Controller 上否则一个请求里多个无关操作共享同一个连接和锁并发上来后很容易出现锁等待。这里有一个小细节MyBatis 的 Mapper 接口方法名不要用 insert/update 这类通用单词最好带业务含义比如 insertWeixiuOrder、updateReplyStatus查日志时能快速定位。3.2 统一返回格式接口返回结构如果每个 Controller 都自己拼 Map小程序端解析起来会很混乱。我一般定义一个 Result 类固定 code、msg、data 三个字段。code 为 200 表示成功401 表示 token 失效500 表示业务异常。小程序端在封装 request 时只需判断 code 就能决定是刷新列表还是跳登录页。public class ResultT { private Integer code; private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT error(Integer code, String msg) { ResultT r new Result(); r.code code; r.msg msg; return r; } }参数说明ok 方法的 data 可以是 List、对象或 null分页接口会把 total 同时放进去error 方法用来在全局异常处理器里返回统一错误信息避免小程序端拿到无法解析的异常堆栈。3.3 登录接口与 token 生命周期登录接口接收 username 和 password校验通过后生成一个随机 token更新到 yonghu 表的 token 字段并把 token 返回给小程序端。后续业务接口的请求头都带 token拦截器根据 token 查出 userId 放入 ThreadLocalController 从 ThreadLocal 取当前操作人的 id。PostMapping(/auth/login) public Result login(RequestBody LoginRequest req) { Yonghu user yonghuMapper.selectByUsername(req.getUsername()); if (user null || !passwordEncoder.matches(req.getPassword(), user.getPassword())) { return Result.error(500, 用户名或密码错误); } String token UUID.randomUUID().toString().replace(-, ); yonghuMapper.updateToken(user.getId(), token); return Result.ok(token); }逻辑说明密码比对用 BCrypt数据库里不存明文token 用 UUID 去掉横线后的随机串写入用户表。毕设这个规模用数据库存 token 就够了不需要引入 Redis。后面并发上来了再把存储替换成 Redis 并给 token 加过期时间演进路径是清晰的一开始就堆缓存组件反而增加部署复杂度。3.4 报修单提交接口实现下面给维修单提交的完整实现。重点是 userId 来自拦截器而不是前端表单。RestController RequestMapping(/api/weixiu) public class GuzhangweixiuController { Autowired private GuzhangweixiuService guzhangweixiuService; PostMapping(/add) public Result add(RequestBody Guzhangweixiu weixiu, RequestAttribute(userId) Integer userId) { weixiu.setYonghuId(userId); return Result.ok(guzhangweixiuService.add(weixiu)); } }Service public class GuzhangweixiuService { Autowired private GuzhangweixiuMapper guzhangweixiuMapper; Transactional(rollbackFor Exception.class) public Guzhangweixiu add(Guzhangweixiu weixiu) { if (weixiu.getGuzhangName() null || .equals(weixiu.getGuzhangName())) { throw new BusinessException(500, 故障标题不能为空); } if (weixiu.getGuzhangTypes() null) { throw new BusinessException(500, 请选择故障类型); } weixiu.setZhuangtaiTypes(1); weixiu.setInsertTime(new Date()); guzhangweixiuMapper.insertWeixiuOrder(weixiu); return weixiu; } }逻辑说明Controller 通过 RequestAttribute 拿到拦截器解析出的 userId然后覆盖前端传进来的 yonghuId。这样即使用户在抓包工具里改了 yonghu_id也无法替别人报修。Service 层的校验是最终防线小程序端的校验可以被绕过但 Service 层不会。insertTime 和 zhuangtaiTypes 都在 Service 层赋值前端提交过来的状态值一律忽略。3.5 拦截器与放行路径配置登录校验用 Spring 拦截器做不依赖每段代码重复写判断。preHandle 里从 Header 拿 token查用户表没有或过期就返回 401有就把 userId 塞进 request attribute。public class LoginInterceptor implements HandlerInterceptor { Autowired private YonghuMapper yonghuMapper; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(token); if (token null || .equals(token)) { throw new BusinessException(401, 未登录); } Yonghu yonghu yonghuMapper.selectByToken(token); if (yonghu null) { throw new BusinessException(401, 登录已过期); } request.setAttribute(userId, yonghu.getId()); return true; } }在 WebMvcConfig 里注册拦截器并配置放行路径。下面的规则里登录、首页公告和轮播图、图片静态资源放行其余全部拦截路径处理方式/auth/login放行/api/home/**放行公告、轮播图/upload/**放行图片静态资源/api/**校验 token其他返回 404放行 /api/home/** 是因为未登录业主也能看首页公告和轮播图房屋列表是否放行看产品设计如果房屋信息公开建议也放行只对提交类接口做登录要求。4. 微信小程序端的房屋查询与报修提交实现小程序端按 tabBar 划分四个主页面首页、房屋、报修、我的。每个页面都从后端拉 JSON 数据用 setData 更新视图。整套数据流很简单前端只关心「渲染什么、提交什么」业务规则全部交给后端。4.1 页面路由与数据流首页展示公告列表和轮播图房屋页展示房屋卡片报修页是表单我的页面展示用户信息和我的维修单入口。数据流上列表页在 onShow 里重新拉取数据而不是只在 onLoad 拉一次。业主切换 tab 回到列表页时数据可能已经变化重新请求的成本很低但能避免「看到已过期数据」的体验问题。接口作用请求方式/auth/login业主登录POST/api/fangwu/list房屋列表GET/api/weixiu/add提交报修POST/api/tousu/add提交投诉建议POST/api/ruzhu/add入住登记POST小程序端不直接操作数据库所有请求都走 request 封装函数统一带 token、统一解析返回码。下面是我常用的封装const baseUrl https://api.example.com function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: baseUrl url, method, data, header: { Content-Type: application/json, token: token }, success: (res) { if (res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) return } resolve(res.data) }, fail: (err) reject(err) }) }) } module.exports { request }参数说明token 存在本地 storage每次请求从 storage 读出并放进 header。后端拦截器拿到 token 后识别登录用户当返回 code 为 401 时统一跳登录页业务页面不需要自己处理登录过期。后端接口都返回同样结构的 JSON前端一个 if 就能覆盖所有情况。4.2 房屋列表与类型筛选房屋列表页的数据渲染用 wx:for 完成。每个房屋卡片展示图片、名称、户型、面积和类型名。类型名不要在前端写死后端根据字典表返回的 map 组装好前端直接用。async loadHouses(typeId) { const res await request({ url: /api/fangwu/list, method: GET, data: typeId ? { fangwuxinxiTypes: typeId } : {} }) if (res.code 200) { this.setData({ list: res.data }) } }view classhouse-card wx:for{{list}} wx:keyid image src{{item.fangwuxinxiPhoto}} modeaspectFill classhouse-img/image view classhouse-name{{item.fangwuxinxiName}}/view view classhouse-meta{{item.fangwuxinxiBuju}} · {{item.fangwuxinxiSize}}/view view classhouse-type{{typeMap[item.fangwuxinxiTypes]}}/view /view逻辑说明loadHouses 接收可选的 typeId为空时拉全量列表非空时按类型过滤。typeMap 是后端把字典表转成对象返回的结果类似于{1: 高层, 2: 洋房}前端用数组下标方式拿到类型名页面底部切换类型时重新调用 loadHouses 即可。注意 wx:key 绑定的是每条的 id不要用 index否则列表删除或重排时渲染状态容易错乱。4.3 报修表单提交与图片上传报修页涉及文本和图片两类数据。图片用 wx.chooseMedia 选择用 wx.uploadFile 传回后端后端返回图片地址后再和表单文本一起提交。顺序不要颠倒否则图片地址还没拿到就提交了。async chooseAndUpload() { const res await wx.chooseMedia({ count: 1, mediaType: [image], sourceType: [album, camera] }) const tempPath res.tempFiles[0].tempFilePath const token wx.getStorageSync(token) wx.uploadFile({ url: baseUrl /api/upload, filePath: tempPath, name: file, header: { token: token }, success: (up) { const result JSON.parse(up.data) this.setData({ uploadedUrl: result.data }) } }) }参数说明wx.chooseMedia 的 count 限制单次选择数量这里限制为 1sourceType 允许相册选图和拍照。wx.uploadFile 的上传参数 name 是后端 MultipartFile 的形参名必须和后端接口接收的字段名一致否则文件收不到。后端转存图片后返回相对路径如 /upload/2024/xxx.jpg页面 img 标签拼接 baseUrl 即可访问。4.4 维修单状态轮询业主提交维修单后希望看到后台处理状态。最简单的方式是 onShow 里启动轮询30 秒请求一次我的维修单列表onHide 时清除定时器。onShow() { this.timer setInterval(() this.loadMyOrders(), 30000) }, onHide() { if (this.timer) { clearInterval(this.timer) this.timer null } }说明一定要在 onHide 里清掉定时器否则页面在后台时请求持续发用户会被手机系统提示耗电过多小程序也可能被微信后台杀掉。轮询间隔 30 秒对这个场景足够不需要 WebSocket真机调试时也可以临时改成 3 秒观察数据变化。5. 真机调试与联调中最值得处理的几个细节5.1 开发者工具能通真机却请求失败如果本地请求 http://localhost:8080 正常换到真机预览后请求一直 fail原因通常是合法域名校验。微信小程序要求所有请求域名在「小程序后台-开发管理-服务器域名」中配置并且必须是 https。开发阶段有两个办法一是在开发者工具「详情-本地设置」勾选「不校验合法域名」二是把接口域名改成已经备案的 https 域名。提交审核前所有后端接口和上传接口都要换成 https并且 wx.request、wx.uploadFile 的域名也要保持一致否则真机上依然被拦截。5.2 setData 更新列表的常见误用直接修改 this.data.list[0].name 不会触发页面渲染因为 setData 才是数据到视图的通道。修改数组中的单个元素时推荐用 key 方式this.setData({ [list[ index ].zhuangtaiTypes]: 2 })这个写法利用小程序的数组路径表达式只更新变化的节点避免整段 list 重新渲染。如果更新后需要展示最新列表直接把接口返回的 res.data 赋值给 list 也行但列表超过 50 条时整段替换会造成明显的渲染抖动。5.3 token 失效后重放请求的技巧token 过期后用户正在填的报修表单会丢失体验很差。我一般在 request 封装里拦截 401把当前的 url、method、data 暂存在 globalData.pendingAction 中跳转登录页。登录成功后回到业务页检查 globalData.pendingAction 是否存在存在就重新发起请求。重放前要确认接口是幂等的否则提交类操作会插入两条数据。我的做法是提交接口带一个前端生成的 requestId后端收到请求后先去表里查这个 requestId存在就直接返回旧结果不存在才插入这样即便请求重放多次数据也只有一份。本文还有配套的精品资源点击获取