SSM+微信小程序房屋租赁系统开发实战：架构设计到部署避坑

简介：在前后端分离开发模式日益普及的今天，SSM（Spring+SpringMVC+MyBatis）作为Java后端经典框架组合，依然是理解Web分层架构与事务控制的理想切入点。而微信小程序凭借轻量、即用即走的特点，成为移动端业务展示与交互的主流容器。将二者结合，构建一个涵盖用户登录、房源检索、订单预约、图片上传等核心场景的房屋租赁系统，不仅能够完整串联从数据库设计、MyBatis动态SQL到小程序原生组件适配的全链路技术栈，还能深入实践HTTP与业务状态码分离、乐观锁防并发等工程化思路。对于毕业设计或简历项目而言，掌握这套从架构选型到真机调试的方法论，远比单纯跑通代码更有价值。本文围绕SSM与微信小程序的集成要点，剖析了前后端联调、状态管理及常见兼容性问题，帮助开发者快速落地一套可演示、可扩展的房屋租赁解决方案。 毕业设计选这个题目的同学，十有八九是冲着“SSM + 微信小程序”这个黄金组合去的。后台用Java写接口，前台用小程序做展示和交互，一个标准的B/S前后端分离项目，既能展示你懂后端框架，又能证明你上手了当下最火的前端容器，加上房屋租赁这个贴近生活、业务逻辑清晰的场景，不管是课程设计、毕业论文还是求职简历，都能拿得出手。

我先给这个项目定个调：这不是一个单纯的前端套壳项目，也不是一个传统的Vue+ElementUI后台管理系统，而是一个“小程序端用户操作 + SpringBoot或SSM后端处理 + MySQL持久化”的三层结构。我最开始做类似项目的时候，踩过不少坑，比如小程序端的登录态怎么和后台session对齐、房源图片上传后怎么回显、预约看房的时间冲突怎么处理等等。这篇文章我会把整条链路拆开揉碎了讲，从架构选型、数据库设计，到核心接口的实现逻辑、小程序端的兼容性问题，再到调试技巧，争取让拿到这份代码的同学能看懂、能跑通、还能在答辩的时候讲清楚每一个环节的为什么。

1. 项目整体设计与技术选型思路

1.1 为什么选SSM而不是SpringBoot

先说结论：SSM在2024年的今天确实已经不是效率最高的选择，SpringBoot可以让你少写一半配置。但在毕业设计和教学场景下，SSM仍然有它不可替代的价值，这也是为什么你拿到的源码大概率还会是SSM框架。

SSM是Spring、SpringMVC、MyBatis三个框架的整合。Spring负责对象管理，SpringMVC负责web层的请求分发，MyBatis负责数据库的ORM映射。这三个框架各司其职，把项目分成清晰的三层结构：Controller层收请求、Service层管业务、Mapper层操作数据库。

如果你的项目里用了SpringBoot，你得清楚它只是把Spring和SpringMVC的配置自动化了，核心的容器原理、AOP切面、事务管理机制并没有变。答辩的时候老师几乎必问一句：“SpringBoot和SSM的区别是什么？”你如果能说出“SpringBoot的本质就是SSM的封装与自动配置，省掉了大量XML配置”，老师基本就知道你是真懂。

对于这个房屋租赁系统来说，SSM的另外一个隐性优势是它的分层结构更适合展示你的事务处理能力。比如订单创建这个动作，需要同时操作订单表、房源状态表、可能还要写入消息通知记录，这三个操作必须在同一个事务里。SSM环境下事务是显式配置的，你能讲清楚事务传播行为，比在SpringBoot里加一行@Transactional更能说明你对底层机制的理解。

1.2 小程序端选型：原生还是uni-app

这是一个很容易被忽略但非常影响开发体验的决策点。你拿到的这个项目，优先选择的是微信小程序原生开发。热词里提到的uni-app、Vue3连接SSM，那是另一个技术路线，不要在答辩的时候把两套东西混在一起讲。

原生小程序的核心优势有两个。第一是微信开发者工具的调试能力强，Network面板能直接看到每个请求的耗时和返回体，Storage面板能可视化查看本地缓存，这些在排查问题的时候效率极高。第二是原生组件对微信底层API的调用最直接，比如wx.login拿code、wx.request发请求、wx.uploadFile传图片，用原生写不会有中间层的兼容损耗。

如果你用过uni-app就会发现，它在真机上偶尔会出现样式偏移或者API调用失败的情况，需要在H5、App、小程序各个端做条件编译。对于这种以小程序为单一目标的毕设项目，完全没有必要引入这一层复杂度。

还有一个细节值得注意：小程序端的文件结构。原生项目的根目录由pages、utils、components、images这些文件夹组成。pages下面的每个页面都包含四个文件——wxml、wxss、js、json，这是一个页面级的组件化结构。很多同学第一次打开项目的时候会被这种结构吓到，其实你只要记住一点：wxml负责结构、wxss负责样式、js负责逻辑、json负责页面级配置，后面就顺了。

1.3 前后端交互的数据格式约定

项目里，前后端的数据交互统一采用JSON格式。你可能觉得这不是什么技术含量的事，但真正统一约定后，联调阶段会省掉大量口舌之争。我给出的约定建议是：

{ "code": 200, "message": "success", "data": { } }

code为200时表示业务成功，data里面放业务数据；code非200时表示业务失败，message里放失败原因。这是一种非常通用的接口返回结构。小程序的request封装里只需要统一判断res.data.code即可，不需要对不同的接口做不同的错误处理。

HTTP状态码和业务状态码一定要分开。有的同学图省事，后端直接返回400、500这种原生状态码给前端，实际上这会导致两个问题：一是微信小程序的wx.request在statusCode非2xx时会走fail回调，但你需要在success回调里才能拿到后端返回的具体错误信息，处理起来很别扭；二是后端一旦把HTTP状态码和业务状态码混用，排查问题的时候你根本分不清是网络层的问题还是业务逻辑的问题。

2. SSM后端核心模块与实现细节

2.1 项目目录结构与启动流程

拿到源码之后，第一步不要急着跑起来，先花十分钟看明白目录结构。标准的SSM项目Maven目录如下：

src/main/java ├── com.rent.controller // Controller层，接口入口 ├── com.rent.service // Service层，业务逻辑 ├── com.rent.dao // Mapper接口层 ├── com.rent.entity // 实体类 ├── com.rent.utils // 工具类 src/main/resources ├── mapper // MyBatis的XML映射文件 ├── spring // Spring和SpringMVC的配置文件 ├── jdbc.properties // 数据库连接配置 └── mybatis-config.xml // MyBatis全局配置

有一个很容易被忽略的细节：src/main/webapp/WEB-INF/web.xml是SSM项目的入口配置文件。它负责监听Spring容器初始化、配置DispatcherServlet、设置编码过滤器。如果启动的时候报容器加载失败，90%的可能是web.xml里的contextConfigLocation路径写错了。

SSM项目的启动流程我再描述一遍，答辩的时候要能用自己的话说出来：Tomcat启动时先读取web.xml，初始化Spring容器并扫描Service和Mapper的Bean，然后初始化SpringMVC容器并扫描Controller，最后当请求进来的时候，DispatcherServlet把请求转发给对应的Controller方法，Controller调用Service，Service通过Mapper操作数据库。

2.2 登录鉴权与微信登录态处理

这个模块是整个项目里最容易被卡住的地方。房屋租赁系统的用户是通过微信小程序进入的，所以登录流程不是传统的用户名密码登录，而是微信授权登录，流程如下：

小程序端wx.login()获取一个临时code，把这个code发送到后端接口，后端拿这个code去微信的服务端换openid，换到openid之后在数据库里查这个用户是否存在，如果不存在则创建一条用户记录，最后再生成一个token返回给前端。

后端生成token最常用的方案是UUID，把openid和token写入数据库，前端后续所有需要登录态的请求都会在header里带上token，后端通过拦截器校验token并取出当前用户信息。

这个流程里最关键的坑在于：不要每次都调微信的接口换openid。有同学会图省事在每次请求时都调微信登录验证，这在开发环境没问题，但微信对小程序的接口调用频次是有限制的。正确的做法是第一次用code换取openid之后，后续只用token来识别用户。

还有一个小程序端特有的启动方式问题。你会在app.js的onLaunch里调用wx.login，得保证这个异步操作完成之后再跳转到首页。否则会出现一个经典的bug：页面已经加载了，但用户信息还没取到，界面上显示默认值或者报“未登录”。解决办法是在app.js里暴露一个loginReady的Promise，页面的onLoad里await这个Promise再执行数据请求。

2.3 房屋及订单业务的状态机设计

标准的房屋租赁系统核心业务逻辑其实不复杂，但状态管理一旦没做好，后面扩展预约、收藏、合同等功能就会寸步难行。

先看房源表的核心状态，我用一个字段status来管理，0代表未出租、1代表已出租、2代表已下架。这个字段看似简单，但它与订单、预约、收藏三个模块都有耦合。举个例子，一个房源正在被某个用户预约看房时，它的status仍然是0，但如果已经签了合同，status就必须改成1。你在下订单的Service方法里需要同时执行两个操作：插入订单记录、更新房源status。这也是前面提到的事务管理发挥作用的地方。

再看订单模块，订单状态is 0待看房、1已完成、2已取消。用户预约看房之后，房东可以在后台确认或者取消预约。“待看房”状态必须有个时间字段，否则就会出现过期预约还在挂在列表里的情况。我在设计表的时候加了一个appointment_time字段，查询时直接用SQL的WHERE appointment_time > NOW()过滤掉过期记录。

房源的状态变化必须通过Service层方法统一控制，不能允许Controller里直接更新status字段。比如用户在前台下单后，前端调用的是POST /order/create，这个接口里会先校验房源状态是否为0，然后再执行事务操作。如果有人在别的地方写了一句update house set status=1 where id=xx，那就绕过了业务校验，可能会把已经被预约但还没付款的房源也标记为已出租，这就是线上事故。

3. 微信小程序前端核心功能拆解

3.1 小程序页面架构与导航设计

小程序端的页面结构通常包含四个主要tab：首页、找房、我的、更多。tabBar是全局配置里最直观的部分，在app.json中配置，每个tab页都要提供一个png图标，被选中和一个未选中两种状态。

首页是信息流展示页，承载的功能是房源推荐和搜索入口。这里要注意一个问题：首页的加载性能直接影响用户留存，而小程序的代码包大小限制是2MB，普通房子装修图一张都要200K左右。我的做法是首页的房源列表接口只返回缩略图URL，不返回原图。在后端存储图片时统一命名规范，比如house_cover_100x100.jpg，前端直接拿这个URL去加载，图片体积小，加载速度快，用户体验好很多。

小区内导航通常就是顶部tab加swiper列表的结构。有个细节容易踩坑：很多同学直接把所有房源放到一个请求里返回，然后前端一次性渲染。这种做法在小规模测试数据下没问题，但一旦房源数据超过几百条，就会出现首屏空白时间过长、页面滚动卡顿的问题。分页查询是必须的，后端用limit和offset做分页，前端通过scroll-view的bindscrolltolower上拉加载下一页。

3.2 房屋列表与搜索筛选的前后端联动

房屋列表页是整个小程序里最核心的展示页面，它承接了搜索、筛选、排序、分页四个基本功能。搜索字段包括小区名称、区域、户型、租金区间，这些条件需要转换成后端MyBatis的动态SQL查询。

<select id="searchHouses" resultType="House"> SELECT * FROM house <where> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR address LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> <if test="type != null and type != ''"> AND type = #{type} </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

注意这段SQL里的#{}和${}的差别。用#{}会生成预编译SQL，能够防止SQL注入，用${}是字符串拼接，优先级在MyBatis里比#{}低，但存在注入风险。电商、金融类的实际项目对这个问题要求极高，但在毕设里你只要全程用#{}就不会出问题。

前端页面上，筛选条件通过一个弹出层实现，用户点击搜索按钮后把条件组装成对象传给后端。这里有一个微信小程序特有的问题：picker组件在低版本基础库上对range和value的类型极其敏感。如果你把价格区间的rangeKey写成number类型，在部分安卓机型上会显示空白。我最终的解决方案是全部用字符串数组，统一做一次parseInt转换。

3.3 图片上传与预览的完整实现

房屋发布页面需要用户上传房源照片，这里的核心痛点在于小程序端的图片上传和普通web端完全不同。

小程序端步骤是先通过wx.chooseMedia选择图片，然后调用wx.uploadFile上传到后端接口。wx.uploadFile的name参数对应后端接收文件的参数名，formData可以额外携带一些业务字段，比如房源id，也可以在上传成功后再通过单独的更新接口来关联。

后端的处理方式是用MultipartFile接收文件，然后通过FileOutputStream写入到本地的upload目录。这里有一个很多人会忽略的问题：写入本地磁盘的文件路径必须和nginx或者Tomcat的虚拟映射目录对应。如果你把文件写到了项目的target/upload目录，但Tomcat的server.xml里映射的是webapps/upload目录，那你上传成功后前端依然无法访问到这个图片。

我习惯的做法是在项目根目录下建一个upload文件夹，然后在spring-mvc.xml里配置一个资源映射：

<mvc:resources mapping="/upload/**" location="/upload/" />

这样前端拿到的图片URL就是http://localhost:8080/upload/xxx.jpg，与后端代码完全解耦。以后如果要把文件迁移到阿里云OSS，只需要把Controller里的存储逻辑替换一下，接口URL的格式完全不需要变。

3.4 微信小程序的常见兼容性与渲染问题

热词里反复出现白屏、单选框、顶部导航高度等问题，这些我在开发中几乎全部遇到过，挑几个典型的说一下。

白屏问题最常见的原因是基础库版本不一致。同一个页面在开发者工具上正常，在真机上就白屏，多数情况是你在wxml里用了较新的组件或API，但真机的微信客户端基础库版本太旧。排查思路是先看Console面板有没有报错，如果没有报错就检查用的API是不是在当前基础库版本里可用。我的做法是在app.json里先声明"libVersion": "2.32.3"这样的固定版本，避免开发者工具和真机的环境不一致。

单选框的问题更隐蔽。小程序里的radio组件和radio-group组件必须搭配使用，而且radio的value属性是必填的，如果不填，选中的时候value就是undefined。另外radio的样式默认是圆形的，要在wxss里通过::before伪元素自定义选中样式，这也是热词里搜索量高的一个原因。

顶部导航栏高度适配问题，其实就是一个公式：导航栏高度 = 状态栏高度 + 标题栏高度。状态栏高度可以通过wx.getWindowInfo()获取，标题栏高度在胶囊按钮出现时是固定的。最保险的做法是直接用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的位置，然后反推出导航栏下半部分的高度。这样写出来的自定义导航栏在刘海屏、灵动岛、各种挖孔屏上都能对齐。

4. 数据库设计与表关系梳理

4.1 核心数据表结构与字段说明

房屋租赁系统的数据库设计，我梳理下来核心表一共6张：用户表user、房源表house、图片表house_image、收藏表favorite、预约订单表appointment、新闻资讯表news。如果要扩展，可以增加反馈表feedback和后台管理员表admin。

用户表的核心字段是openid和nickname。openid是微信用户的唯一标识，长度建议设为64，因为微信的openid在部分场景下会超过32位。nickname前端传什么就存什么，注意设置默认值“微信用户”，否则会有很多空值。

房源表是所有业务的核心载体，字段要尽量齐全：title房源标题、cover封面图、address详细地址、area面积、price租金、type户型、status状态、description描述、create_time发布时间、owner_id房东id。这里有一个值得一提的设计细节：封面图cover不要单独建表，因为它只是一条URL字符串，建表反而增加JOIN的复杂度。而多图场景属于一对多关系，必须单独建house_image表，字段包含house_id、url、sort排序号。

预约表单需要重点看的是唯一性约束。我建表的时候给(house_id, user_id, appointment_time)加了一个联合唯一索引，从数据库层面防止同一个用户在同一时间段重复预约同一套房源。这种做法在并发场景下比Service层先查后插更安全，因为MyBatis的查询和插入之间如果有并发，后插入的记录会直接触发唯一索引冲突，数据库会帮我们拦下来。

4.2 MyBatis动态SQL与多表关联查询

在房屋列表页有一个高频查询场景：前端请求房源列表时，需要展示封面图、房东昵称、收藏状态。这是一个典型的多表关联场景，我的Mapper写法是：

<select id="getHouseList" resultType="map"> SELECT h.*, u.nickname as ownerName, (SELECT COUNT(*) FROM favorite f WHERE f.house_id = h.id AND f.user_id = #{userId}) as isFav FROM house h LEFT JOIN user u ON h.owner_id = u.id <where> <if test="keyword != null and keyword != ''"> AND (h.title LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY h.create_time DESC LIMIT #{offset}, #{pageSize} </select>

这段SQL里有个性能隐患值得说一下：isFav这个字段用了子查询，每行记录都要执行一次COUNT查询。当房源表数据量增大到万级以上时，这个查询会明显变慢。优化方案是把这个子查询改成LEFT JOIN，把favorite表关联进来，再通过GROUP BY去重。虽然改动不大，但这是一个很好的面试和答辩加分点。

还有一个多表查询常见的问题是resultType="map"导致字段类型丢失。比如house表的price字段在MySQL里是DECIMAL类型，如果用map接收，MyBatis返回给前端时会是字符串，前端在计算总价时如果直接相加就会出现字符串拼接的情况。我的建议是创建HouseVO实体类，把price定义成BigDecimal类型，这样返回的JSON就是一个数字。

4.3 数据库初始化与测试数据填充

拿到项目后的第一件事就是建库。我的数据库名固定是db_house_rental，字符集用utf8mb4。这里强调一下，字符集一定不能图省事用默认的utf8，因为utf8在MySQL里最多只能存3字节的UTF-8字符，遇到emoji表情会直接报错，而utf8mb4是完整的4字节编码，兼容所有字符。

初始化脚本里除了建表语句，还应该包含一批测试数据。我在填充测试房源时有个经验：标题一定要真实自然，比如“徐家汇地铁站旁精装一室一厅，拎包入住”，不要用“测试房源1”这种敷衍的名称。因为这关系到前端搜索功能能否直观地验证效果，如果所有房源标题都是数字和测试字样，你很难在真机上判断搜索的逻辑是不是正确。

数据填充的技巧是每张表至少准备10条以上记录，并且要覆盖各种边界条件。比如房源的status要有0和1两种状态，户型至少要包含一室、两室、三室，价格区间要从2000到15000都覆盖到。这样后续测试筛选和分页功能时数据才能形成梯度。

5. 生命周期、接口联调与常见问题排查

5.1 小程序request封装与统一处理

小程序端和后端联调时，最大的痛点是没有类似axios这种现成的库，必须自己封装一个request方法。我贴一个自己常用的封装，这个封装主要干了三件事：统一处理baseURL、携带登录token、统一处理HTTP异常。

const BASE_URL = 'http://localhost:8080' function request(url, method, data) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method || 'GET', data: data || {}, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.message, icon: 'none' }) reject(res.data) } }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }) reject(err) } }) }) }

有一个非常容易被忽略的细节：开发环境的小程序必须要在微信开发者工具的“详情”->“本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，否则请求http://localhost:8080会被微信直接拦截。这个坑几乎每个第一次做小程序的人都会踩。

联调的时候还会遇到一个前后端不同步的问题：后端改了接口参数名，但前端忘了同步。解决办法是后端用Swagger生成API文档，前端直接看文档调用。如果你的项目里没集成Swagger，可以在后端接口的注释里写清楚参数含义，配合Postman的使用，基本能保证调试顺畅。

5.2 部署环境与常见启动报错整理

本地启动这个项目的最简方案：安装JDK8、Maven、MySQL5.7或8.0、Tomcat8.5。我的建议是JDK一定要装8，因为项目里的CGLIB代理和Spring版本在JDK11或17上可能出现兼容性问题。Maven用3.6版本以上都可以。

启动报错排查看这里：

最后一个跨域问题要单独解释一下。小程序端wx.request从技术上讲不受浏览器的同源策略约束，所以理论上不存在跨域问题。但在真机上会有两个限制：必须配置request合法域名且必须是HTTPS协议，以及不能直接用IP地址必须使用备案域名。这也就是为什么很多同学的手机真机预览都会失败，而开发者工具却能正常运行。解决方法是把后端的接口部署到一台有公网IP的服务器上，用nginx做HTTPS反向代理。

5.3 线上部署的扩展建议

如果只是提交毕业设计，本地运行就够了。但如果想把这个项目放到云服务器上跑起来，或者想作为简历上的亮点项目，有几个扩展建议可以留意一下。

文件存储方面，我强烈建议把房源图片从本地磁盘迁移到OSS或COS对象存储。迁移改造的核心逻辑很简单：把上传接口里的本地文件写入逻辑替换成调用云存储SDK的putObject方法，然后把返回的URL存到数据库。这样图片的访问不再依赖Tomcat服务器的磁盘空间和带宽，也不怕服务重启时文件丢失。

小程序端的用户体验优化方面，可以给首页增加骨架屏。微信小程序原生的view没有skeleton组件，需要自己去画一个假的页面结构，让用户在等待首屏的时候而不是看到一个空白。核心实现是在页面的data里加一个isLoading字段，用wx:if控制骨架屏和真实内容的切换。

如果你还想把这个项目作为求职项目，建议把单机部署升级成Docker Compose编排。写一个docker-compose.yml，把MySQL和后端服务分别打包成镜像，一条命令就能启停整个环境。面试官看到这个细节会认为你有一定的工程化意识，比单纯在简历上写“熟练使用SSM框架”有说服力得多。

5.4 关于接口压测与并发场景的预防

房屋租赁系统最容易被老师追问的点就是并发，比如“多个用户同时预约同一个房源怎么办”。如果只是从数据库层面做校验，在并发量大的时候确实会出现超卖。解决思路有两个层面。

第一层是数据库乐观锁。在house表增加一个version字段，更新房源状态的SQL写成：

UPDATE house SET status = 1, version = version + 1 WHERE id = #{id} AND version = #{version}

如果执行后受影响的行数为0，说明有其他请求已经修改了这行记录，当前请求就返回“手慢了，房源已被抢订”。

第二层是分布式锁。对于单机部署的项目，用Redisson或者Redis的SETNX命令实现锁就够用了。在创建订单之前先获取锁，锁的key可以设计成booking:house:{houseId}，锁的过期时间设置为10秒。释放锁的时候要注意判断是否当前线程持有锁，否则可能出现误删别人锁的情况。这部分不必写进毕设代码里，但是答辩时能清楚讲出这个方案，会显得你在处理并发问题上有清晰的思路。

6. 踩坑实录与避坑指南

6.1 小程序端疑难杂症速查表

我把开发这个项目过程中实际遇到、且具有代表性的问题整理成了一张速查表，其中一部分在热词里频繁出现，说明是大家的共性问题：

6.2 数据一致性隐患：前端缓存和异步更新

小程序端的缓存机制跟浏览器很像，用了wx.setStorageSync之后，数据会一直保留在本地，直到用户手动清除缓存。这个机制在处理用户登录态时很方便，但也会带来一个隐患：如果你在“我的”页面缓存了用户信息，而用户在别处更新了头像或者昵称，“我的”页面很可能显示的还是旧数据。

我的经验是在封装request的时候，凡是请求成功就顺手更新本地缓存的用户信息，这样“我的”页面每次onShow的时候从storage里重新读取，数据就是最新的。另一种更稳妥的办法是在“我的”页面的onShow生命周期里调用后端接口重新拉取用户信息。虽然会多一次网络请求，但能彻底避免脏数据。

还有一个非常容易踩的坑是setData的异步执行。小程序的setData并不是同步更新的，在调用setData之后立刻用this.data获取，拿到的很可能还是旧值。如果你需要在setData之后执行一段依赖新状态的逻辑，必须写在setData的回调里，而不能写在setData之后紧接着的代码行里。

6.3 Tomcat热部署与调试技巧

SSM项目的开发调试效率，很大程度取决于Tomcat的热部署配置。如果你的IDEA配置了热部署，改完Java代码后Ctrl+F10就能生效，不用重启Tomcat。但实际开发中经常出现改了代码之后，刷新页面却还是旧效果的情况。这时候不要急着怀疑热部署没生效，先看一下Tomcat的catalina.out日志，确认是不是编译报错了。

排查接口问题时还有一个技巧：在后端Controller的每个方法入口加一行日志，打印请求参数和返回结果。Spring的@Slf4j注解加在类上，然后通过log.info打印日志。开发阶段你可以用System.out.println，但答辩演示前最好全部换成日志框架，不然输出刷屏很影响调试体验。

小程序端的调试也是老生常谈。Console面板能看到console.log输出，Network面板能看到每个请求的详情。很多同学忽略的是Storage面板和AppData面板，它们才是排查缓存和数据绑定问题的利器。AppData够清晰，可以看到当前页面data里的所有字段值，你只要对比一下界面显示和data里的值，就能判断是数据更新了但界面没刷新，还是数据本身就没更新对。

6.4 答辩前的功能自查清单

每次做完一个模块、或者准备提交一份完整项目前，强烈建议按这个清单过一遍：注册登录流程是否完整；房源发布时图片上传是否稳定；列表页分页是否正常，下拉加载是否重复触发；搜索筛选条件是否都生效；收藏功能是否实时刷新列表状态；预约看房后后端状态是否正确更新；后台管理端是否能正常处理预约；接口异常时前端是否给用户明确的错误提示。

把这些功能点全部亲手跑一遍，并且观察浏览器或开发者工具里有没有红色报错，再准备一份接口文档和表结构说明，这个项目就算真正立住了。

7. 项目扩展方向与个人体会

这个房屋租赁系统改造成长租公寓管理系统也非常顺。在现有预约订单表的基础上增加合同表和账单表，把房东端做成一个管理后台，租客端保留小程序，整个业务从“信息撮合平台”升级成了“租住全生命周期管理平台”。这个扩展方向在简历里写“已具备向长租公寓全流程管理系统演进的能力”，比纯粹写“实现了房屋租赁功能”要高级不少。

我当初做类似项目的时候，最有成就感的一个瞬间，不是把代码跑通的那一刻，而是第一次用真机预览，在小程序里发了第一条房源申请，后端Tomcat日志里准确打出了我提交的JSON参数，数据库里也写入了一条新记录。那种前后端真正打通的感觉，比把代码跑起来更让人踏实。

最后再分享一个非常实用的小技巧：接口调试时一定要养成看返回值的习惯，不要只盯着前端界面。界面显示没有变化，不一定是没数据，有可能是数据返回了但前端渲染出了问题。我遇到过很多次，页面一直是空白，其实Network里的响应已经返回了完整的JSON，只是wxml里某个字段名拼写错误。这时候把Network面板打开、把响应体看一遍，很多问题就能瞬间定位。

这个项目做下来，学到的不仅是SSM的配置、小程序的组件用法，更重要的是建立了一种“前端发请求、后端处理业务、数据库存数据”的整体思维模型。把这个模型吃透，以后不管换成什么框架、什么前端容器，核心思路都是不变的。希望这些经验能帮你少走一些弯路，把精力真正花在业务逻辑和项目打磨上。

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