SSM+微信小程序房屋租赁管理系统：从数据库设计到接口联调全解析

简介：面向毕业设计的房屋租赁管理小程序完整资源包，基于微信小程序+SSM+MySQL开发，适合计算机相关专业学生用于毕设参考、功能扩展或代码学习。压缩包共891个文件，大小59.15MB，涵盖Java后端、Vue后台管理、微信小程序前端与SQL数据库脚本；其中vue/java/js构成主要程序代码，png/svg为界面素材，xml/wxml/wxss为配置与样式文件，sql为数据库脚本，mp4为操作演示视频。系统后端包含管理员和中介两类角色，实现房屋信息、租房订单、信息管理、账单管理、房源管理等模块，用户可查看房源并管理个人租房记录。资源附有毕业论文（涵盖系统分析、功能设计和数据库设计）、详细目录结构以及1-install.bat、2-run.bat、3-build.bat等运行脚本，帮助快速部署和二次开发。目前已有199人学习下载，适合需要完整毕设方案或SSM小程序开发范例的读者。

1. 毕业设计为何选SSM+微信小程序做房屋租赁管理系统

拿到这套源码包，等于拿到一个三端齐全的完整项目：微信小程序端面向租客，管理后台面向中介与管理员，后端用SSM框架接MySQL。它覆盖了租房业务里的核心链路——用户浏览房源、提交订单、生成账单，中介维护房源、确认订单，管理员管全量数据。适合两类人：一类是准备毕业设计的学生，需要可运行、可讲清架构、能应对追问的完整系统；另一类是刚学完Java想看看真实工程怎么组织的开发者。为什么强调SSM而不是Spring Boot？因为SSM的分层和配置都暴露在外，MyBatis的SQL可解释性也更强，答辩时“请求怎么进来、SQL怎么写”都能展开说。下面按技术选型、数据库、接口对接、部署演示四个阶段拆解。

2. 技术栈选型与工程组织：SSM、Vue后台和小程序端的边界划分

2.1 为什么还选SSM框架

很多人一看到SSM会说这是几年前的框架，为什么不直接上Spring Boot。放到毕业设计语境里，SSM反而有两个实际优势：第一，SpringMVC的Controller、Service、Dao三层是显式分包，评审老师一眼能看到项目结构，讲项目时可以理直气壮地拆开“从请求怎么进来讲到SQL怎么写”；第二，MyBatis把SQL写在XML或注解里，比JPA那种高度封装的ORM更容易解释“为什么这个查询慢”“为什么分页这么写”。Spring Boot虽然启动快，但自动配置会掩盖掉不少原本要讲的点。

这套项目后端用的是Java的SSM框架，管理后台能看到Vue和Element UI的痕迹，前台小程序运行在微信开发者工具中。三者通过JSON交换数据，后端只暴露接口，前端不直接连数据库。这个边界清晰，以后要迁移到Spring Boot时，业务层的Service和Mapper基本不用动，主要换掉的是配置方式，这也是我把技术选型放在第一位的理由。

2.2 前端管理后台与小程序端的目录结构

源码包里可以看到main.css.bak、IndexAsideStatic.vue.bak、BreadCrumbs.vue.bak这些带.bak后缀的Vue文件，说明管理后台是在Vue加Element UI工程上改出来的。常见布局是左侧菜单（IndexAsideStatic）、顶部Header（IndexHeader）、面包屑（BreadCrumbs）组成后台框架，页面文件放在views下对应业务模块。典型工程结构如下：

rent-miniapp/ ├── backend/ # SSM后端工程 │ ├── src/main/java # controller/service/mapper 三层 │ ├── src/main/resources # spring-mybatis.xml、spring-mvc.xml │ └── sql/ # 建库脚本与演示数据 ├── admin-web/ # Vue管理后台 │ ├── src/views/ # 用户管理、房屋信息、订单等页面 │ └── src/components/ # IndexHeader.vue 等后台布局组件 └── miniapp/ # 微信小程序端 ├── pages/index/ # 首页、房屋列表 ├── pages/order/ # 租房订单、账单 └── utils/request.js # wx.request 封装

需要说明的是，这是按后端、管理端、小程序端三个工程组织的常规方式，源码包里某个目录可能合并了admin-web与backend，跑通后建议按上面目录做一次整理，答辩展示结构会清晰很多。小程序端页面数量不需要多，核心是首页房源列表、详情页、订单页、账单页、个人中心这几个就够了，页面多了反而不好维护。

2.3 .bak备份文件与构建脚本的处理思路

项目正文里出现3-build.bat、2-run.bat、1-install.bat，结合.bak文件，可以判断工程经历过手改大版本的阶段。.bak是改坏后留后路的习惯，留着不删没问题，但答辩前建议做一次清理，避免评审老师翻目录时看到一堆备份文件。另外org.eclipse.wst.common.component和.classpath是Eclipse遗留的工程描述文件，用IDEA打开时可以直接忽略，不影响编译。

# 统计项目里有多少备份文件 find . -name "*.bak" -type f | wc -l # 确认无用的备份后删除 find . -name "*.bak" -type f -delete # 处理完确认管理后台可正常编译 cd admin-web && npm install && npm run dev

清理备份文件后一定要回编译一次，防止某些.bak其实是被引用的资源。三个bat文件的职责一般是这样：1-install.bat负责安装依赖，包括Maven依赖或npm install；2-run.bat负责启动后端服务并打开Tomcat；3-build.bat负责打生产包。在Windows答辩机上按1到3的顺序执行能减少环境问题，如果安装依赖那步特别慢，先检查Maven仓库位置，把settings.xml里的镜像源换到国内仓库。

2.4 微信开发者工具与Java后端联调的网络配置

小程序端请求后端接口时，最常踩的坑是http://localhost:8080在真机上访问不到。后端如果在本机跑，localhost只对本机有效，模拟器里可以，真机预览时必须把地址换成电脑的局域网IP，比如http://192.168.1.100:8080。另外微信开发者工具默认对接口域名做合法性校验，开发期要手动关闭，操作路径是详情-本地设置-勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。

以下几个配置项是联调时最常需要确认的位置：

3. 数据库设计：房屋租赁主流程的表结构与角色权限

3.1 三种角色与五个核心业务实体

管理员、中介、用户三种角色的权限边界，是靠表职责分开的。管理员功能包括用户管理、中介管理、房屋信息管理、房屋类型管理、租房订单管理、租房信息管理、租房账单管理、房源管理、系统管理等；中介主要负责房屋信息、租房订单、租房信息；用户端只暴露房屋浏览、个人信息、订单、账单。映射到数据库，核心是五类实体：账号类（管理员、用户、中介）、房屋类（房屋信息、房屋类型）、交易类（租房订单、租房信息）、账单类（租房账单）。

3.2 建库建表SQL与字段约束

以下是这套系统最核心的几张表，按MySQL常见部署在5.7或8.0上的写法兼容。存储引擎用InnoDB，字符集用utf8mb4，避免小程序传中文出现乱码。

CREATE DATABASE IF NOT EXISTS rent_system DEFAULT CHARACTER SET utf8mb4; USE rent_system; -- 用户表 CREATE TABLE user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), phone VARCHAR(20), avatar VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 中介表 CREATE TABLE intermediary ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, company VARCHAR(100), contact_name VARCHAR(50), phone VARCHAR(20), status TINYINT DEFAULT 1 COMMENT '1启用 0停用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='中介表'; -- 房屋类型表 CREATE TABLE house_type ( id INT AUTO_INCREMENT PRIMARY KEY, type_name VARCHAR(50) NOT NULL COMMENT '整租/合租/单间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房屋类型表'; -- 房屋信息表 CREATE TABLE house ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, type_id INT NOT NULL COMMENT '关联house_type.id', area DECIMAL(10,2) COMMENT '面积', price DECIMAL(10,2) NOT NULL COMMENT '月租金', address VARCHAR(255), pic VARCHAR(255) COMMENT '图片路径', status TINYINT DEFAULT 0 COMMENT '0未租 1已租 2下架', intermediary_id INT COMMENT '维护该房源的中介', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_type (type_id), KEY idx_status (status), CONSTRAINT fk_house_type FOREIGN KEY (type_id) REFERENCES house_type(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房屋信息表'; -- 租房订单表 CREATE TABLE rent_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号', house_id INT NOT NULL, user_id INT NOT NULL, intermediary_id INT COMMENT '接单中介', start_date DATE NOT NULL, end_date DATE NOT NULL, total_price DECIMAL(10,2) NOT NULL COMMENT '总费用', status TINYINT DEFAULT 0 COMMENT '0待确认 1已确认 2已完成 3已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租房订单表'; -- 租房账单表 CREATE TABLE rent_bill ( id INT AUTO_INCREMENT PRIMARY KEY, bill_no VARCHAR(32) NOT NULL UNIQUE, order_id INT NOT NULL COMMENT '关联rent_order.id', amount DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0 COMMENT '0未缴 1已缴', due_date DATE, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租房账单表';

这段SQL有几个可以讲给评审听的点：house.type_id加了外键，保证房屋类型管理不会出现孤儿数据；rent_order用order_no作业务编号，内部主键仍自增，是“内部自增主键加外部业务编号”的常见做法；账单金额在下单时就算好写入rent_bill，不直接读house.price，避免后续改价影响历史账单。

3.3 订单状态流转与账单生成逻辑

租房订单的状态字段用TINYINT：0待确认、1已确认、2已完成、3已取消。正常流转路径是：用户在微信小程序提交订单，状态变为待确认；中介在后台确认房源可租，状态变已确认；租期到期或双方确认退房后变已完成；用户未缴费或中介拒绝时，订单取消。状态只能按顺序迁移，代码里用if判断当前状态再执行下一步，不要直接覆盖，这个细节比在数据库里做复杂约束更可控，也更容易在答辩时演示。

账单的生成时机放在“订单确认”动作里：中介点确认时，程序读取订单总金额，插入一条rent_bill记录。如果要加逾期提醒，最简单的是每天跑一次定时查询，条件是due_date < CURDATE() AND status = 0，查出未缴账单后给用户推送小程序订阅消息。毕业设计里定时任务可以用Spring的@Scheduled注解，不用引入Quartz。

3.4 演示数据初始化与常见索引

毕设演示最重要的是“数据看起来真实”。房源表的演示数据建议覆盖三种类型、两种状态，价格梯度从800到5000元，图片直接用本地路径或占位图。初始化脚本单独存成demo_data.sql，不要和生产数据混在一起。索引方面，除了外键索引，建议给rent_order的user_id、intermediary_id、house_id三个字段各建一个普通索引，因为小程序首页列表、用户订单列表、中介待处理列表是访问频率最高的三块，全部走WHERE查询，数据量超过一万行时就能看出区别。

4. SSM后端开发与小程序端接口对接

4.1 SpringMVC与MyBatis的配置要点

SSM框架中常见配置是spring-mybatis.xml与spring-mvc.xml分开，数据源信息放jdbc.properties，然后在web.xml中统一加载。关键点有三个：数据库连接串、Mapper扫描、Controller包扫描。连接串建议带上useSSL=false和characterEncoding=utf8两个参数，避免小程序传回中文时出现乱码；如果数据库是8.x，驱动类要用com.mysql.cj.jdbc.Driver。下面是数据源与MyBatis配置的核心片段：

<context:property-placeholder location="classpath:jdbc.properties"/> <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.rent.mapper"/> </bean>

MapperScannerConfigurer指定了接口所在包，MyBatis会自动为接口生成代理实现，Service里直接@Autowired注入接口即可。这里有个常见报错是启动时报“no bean named xxxMapper”，多半是basePackage和接口包名不一致，或者mapperLocations指向的XML路径不对，对照上面配置逐项检查即可。

4.2 房屋信息列表接口：Controller、Service、Mapper三层实现

“用户在小程序首页看到在租房源”是整套系统最完整的链路，值得走一遍。先看Controller层，负责接收小程序传过来的分页参数和搜索关键词：

@Controller @RequestMapping("/api/house") public class HouseController { @Autowired private HouseService houseService; @ResponseBody @RequestMapping("/list") public Map<String, Object> list( @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer limit, @RequestParam(required = false) String keyword) { return houseService.queryPage(page, limit, keyword); } }

Service层负责组装返回结构，这里用PageHelper作为分页插件，只对紧跟着的第一条查询生效：

public Map<String, Object> queryPage(Integer page, Integer limit, String keyword) { PageHelper.startPage(page, limit); List<House> list = houseMapper.selectOnRent(keyword); PageInfo<House> info = new PageInfo<>(list); Map<String, Object> result = new HashMap<>(); result.put("rows", info.getList()); result.put("total", info.getTotal()); return result; }

Mapper接口与XML对应SQL如下，直接手写SQL而不走MyBatis Generator自动生成，是这类毕设想拿高分的常见做法，至少在“房屋信息列表”这个接口上要把SQL写完整：

public interface HouseMapper { List<House> selectOnRent(@Param("keyword") String keyword); }

<select id="selectOnRent" resultType="com.rent.entity.House"> select * from house where status = 0 <if test="keyword != null and keyword != ''"> and (title like concat('%', #{keyword}, '%') or address like concat('%', #{keyword}, '%')) </if> order by create_time desc </select>

这一段的逻辑说明：PageHelper.startPage必须在查询语句执行之前调用，它只作用于下一条查询；selectOnRent里status等于0过滤了已租和下架的房源，小程序端拿到的始终是当前能租的数据；keyword判空放到XML里而不是Java里拼SQL，是为了让没有关键词时走普通WHERE，不生成无意义的or条件。整个链路是：小程序发来page和limit，Controller接收参数，Service启动分页，Mapper执行查询，结果封装成Map返回，小程序再解析JSON渲染列表。

4.3 小程序端wx.request请求与登录态保持

小程序端访问后端接口，统一用wx.request。为了避免每个页面都写一遍url前缀，建议在utils/request.js里封装一次：

const BASE_URL = 'http://localhost:8080/rent'; 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/x-www-form-urlencoded' }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else { reject(res); } }, fail: reject }); }); } module.exports = { request };

这里的核心变量是Content-Type。SSM后端如果是用@RequestParam接参数，小程序必须用application/x-www-form-urlencoded，POST的数据会被拼成表单键值对；如果后端接口用@RequestBody接JSON对象，header则要改成application/json。两个头写反，最常见的症状是后端收到null参数，但网络面板里明明能看到请求数据。

登录态保持的简单方案，是用户登录成功后把后端返回的token存入wx.setStorageSync，之后每次请求在header加一个自定义字段，后端用拦截器校验。如果只做毕设演示，也可以不做拦截器，但至少把存储token的代码写出来，后续扩展时不用动请求层。具体写法是wx.setStorageSync('token', res.data.token)，再在request函数里读取。

4.4 参数绑定、JSON解析与错误码约定

后端返回给小程序的数据，建议统一成固定结构：code为0时表示正常，data存放列表或对象信息，msg存放错误信息。这样小程序端可以做统一的错误提示，而不是每个页面判断不同字段。典型接口返回格式：

{ "code": 0, "msg": "success", "data": { "rows": [], "total": 0 } }

接口清单可以按角色拆开，方便在毕业论文里写接口说明：

写接口时注意字段命名规范：数据库字段用下划线，比如house_id，JSON统一用驼峰houseId，管理端和小程序解析时都会省很多事。如果后端MyBatis开启mapUnderscoreToCamelCase参数，一行配置就能自动完成转换。

5. 部署、排错与答辩演示技巧

5.1 三个脚本的启动顺序

从命名看，1-install.bat、2-run.bat、3-build.bat对应Windows环境下的标准动作：install安装依赖，run启动后端服务，build打生产包。拿到源码后建议按顺序各跑一遍，如果2-run.bat一闪而过，先用java -version确认JDK版本，再检查后端pom.xml里配置的编译级别是否和本机一致。这里有个小技巧：不要相信脚本一次能过，Windows下最常见的失败原因是路径带中文或空格，把项目解压到D:\rent\这种纯英文目录再执行，能省很多时间。

5.2 小程序端联调与真机预览设置

小程序要在开发者工具中导入miniapp目录，AppID可以用测试号。联调时后端在本机跑，模拟器直接填localhost即可；真机预览必须把接口地址改为电脑的局域网IP，且手机和电脑连同一个Wi-Fi。如果改了IP还是报超时，先检查Windows防火墙是否放行了Tomcat端口，这一步比反复看代码更快。开发者工具控制台自带Network面板，请求失败时可以直接看到状态码，便于判断是后端没启动、接口404还是参数错误。

5.3 常见报错排查表

整理一组在跑这套项目时会遇到的典型问题：

这个表里的前三条可以过滤掉百分之八十的运行问题。页面白屏但后端有日志的情况，多半是管理端npm run build产物没更新，重新执行3-build.bat并刷新浏览器缓存即可。

5.4 答辩时如何把租房订单闭环讲清楚

毕业设计演示不要按功能列表一个个点，那样显得像在测试系统。最稳的顺序是：管理员登录打开首页，展示系统导航和统计数字；切换中介账号发布一套房源；切回小程序模拟用户浏览；用户提交租房订单；切回中介账号确认订单；系统自动生成账单；用户在小程序端查看账单。这一条链路走下来，三个角色权限、五张核心表、前后端交互全部覆盖。视频演示文件可以按这个顺序录制，重点停留三个画面：小程序提交订单前确认房源信息的页面、中介确认订单后状态变化的列表、账单生成后的金额和日期。老师追问系统哪里难，就回答订单状态流转和账单联动生成的设计，把3.4和4.4的内容串起来说，比空讲用了什么框架更有说服力。

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