简介在前后端分离开发模式日益普及的今天SSMSpringSpringMVCMyBatis作为Java后端经典框架组合依然是理解Web分层架构与事务控制的理想切入点。而微信小程序凭借轻量、即用即走的特点成为移动端业务展示与交互的主流容器。将二者结合构建一个涵盖用户登录、房源检索、订单预约、图片上传等核心场景的房屋租赁系统不仅能够完整串联从数据库设计、MyBatis动态SQL到小程序原生组件适配的全链路技术栈还能深入实践HTTP与业务状态码分离、乐观锁防并发等工程化思路。对于毕业设计或简历项目而言掌握这套从架构选型到真机调试的方法论远比单纯跑通代码更有价值。本文围绕SSM与微信小程序的集成要点剖析了前后端联调、状态管理及常见兼容性问题帮助开发者快速落地一套可演示、可扩展的房屋租赁解决方案。 毕业设计选这个题目的同学十有八九是冲着“SSM 微信小程序”这个黄金组合去的。后台用Java写接口前台用小程序做展示和交互一个标准的B/S前后端分离项目既能展示你懂后端框架又能证明你上手了当下最火的前端容器加上房屋租赁这个贴近生活、业务逻辑清晰的场景不管是课程设计、毕业论文还是求职简历都能拿得出手。我先给这个项目定个调这不是一个单纯的前端套壳项目也不是一个传统的VueElementUI后台管理系统而是一个“小程序端用户操作 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调用ServiceService通过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 status1 where idxx那就绕过了业务校验可能会把已经被预约但还没付款的房源也标记为已出租这就是线上事故。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 idsearchHouses resultTypeHouse SELECT * FROM house where if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR address LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if testtype ! 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 idgetHouseList resultTypemap 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 testkeyword ! 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去重。虽然改动不大但这是一个很好的面试和答辩加分点。还有一个多表查询常见的问题是resultTypemap导致字段类型丢失。比如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版本以上都可以。启动报错排查看这里报错现象原因解决办法404 Not Found项目没有被正确部署到Tomcat检查web.xml存在检查项目发布名称数据库连接失败jdbc.properties里的URL、账号、密码错误检查MySQL服务是否启动核对账号密码Invalid bound statementMapper接口和XML文件没有对应检查XML文件在mapper目录下检查namespace中文乱码编码过滤器没配置在web.xml中配置CharacterEncodingFilter为UTF-8前端请求跨域小程序域名校验或CORS配置缺失开发环境勾选不校验域名后端配置全局CORS最后一个跨域问题要单独解释一下。小程序端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 小程序端疑难杂症速查表我把开发这个项目过程中实际遇到、且具有代表性的问题整理成了一张速查表其中一部分在热词里频繁出现说明是大家的共性问题问题原因解决方案真机白屏开发者工具正常基础库版本不一致或API不兼容固定基础库版本查看报错信息radio单选框样式丢失没有配置radio-group的valueradio必须放在radio-group里value必填顶部导航栏高度混乱没有适配刘海屏和胶囊按钮使用wx.getMenuButtonBoundingClientRect计算wx.request请求失败域名未校验或HTTPS证书未配置开发环境开启不校验上线配置合法HTTPS域名预览图片显示不出图片URL为localhost或相对路径替换为完整可访问的后端地址atob函数无法使用基础库不支持自己写一个base64解码函数分包异步化报错页面放错分包或依赖错误使用require.async加载代码包6.2 数据一致性隐患前端缓存和异步更新小程序端的缓存机制跟浏览器很像用了wx.setStorageSync之后数据会一直保留在本地直到用户手动清除缓存。这个机制在处理用户登录态时很方便但也会带来一个隐患如果你在“我的”页面缓存了用户信息而用户在别处更新了头像或者昵称“我的”页面很可能显示的还是旧数据。我的经验是在封装request的时候凡是请求成功就顺手更新本地缓存的用户信息这样“我的”页面每次onShow的时候从storage里重新读取数据就是最新的。另一种更稳妥的办法是在“我的”页面的onShow生命周期里调用后端接口重新拉取用户信息。虽然会多一次网络请求但能彻底避免脏数据。还有一个非常容易踩的坑是setData的异步执行。小程序的setData并不是同步更新的在调用setData之后立刻用this.data获取拿到的很可能还是旧值。如果你需要在setData之后执行一段依赖新状态的逻辑必须写在setData的回调里而不能写在setData之后紧接着的代码行里。6.3 Tomcat热部署与调试技巧SSM项目的开发调试效率很大程度取决于Tomcat的热部署配置。如果你的IDEA配置了热部署改完Java代码后CtrlF10就能生效不用重启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的配置、小程序的组件用法更重要的是建立了一种“前端发请求、后端处理业务、数据库存数据”的整体思维模型。把这个模型吃透以后不管换成什么框架、什么前端容器核心思路都是不变的。希望这些经验能帮你少走一些弯路把精力真正花在业务逻辑和项目打磨上。本文还有配套的精品资源点击获取