当回忆牵手未来先说点难听的：这类“基于XX小程序的XX系统”源码，每年毕业季能堆满整个网盘，但大部分拿到手你会发现，看来看去就是个增删改查壳子，房源表加一个小区名字段，收藏按钮调一下 setStorage，就敢叫“房屋租赁系统”。你拿去给老师演示，第一页还能讲两句，问到“合同状态是谁在维护”“逾期账单怎么通知租客”，当场卡壳。
我这套项目在设计的时候，就没打算走那个老路。房屋租赁听起来是个老题目，但它其实是小程序里少有的、能把“信息撮合 + 交易履约 + 多角色权限 + 消息触达”全部跑通的业务场景。这次的复盘，我把做这套 [含文档+PPT+源码] 房屋租赁小程序时踩过的坑、想清楚的逻辑、以及哪些地方值得你在文档和答辩里重点包装，一次性写透。内容适合正在做毕业设计、或者打算把小程序作品集再做扎实一点的人参考。
1. 先搞清楚：这个系统到底租给谁住
很多人的“房屋租赁系统”做成什么样呢？一个小程序，里面有个房源列表，点进去能看几张图，然后没有然后了。房源发布靠管理员在后台上传，租客看到合适房源除了打电话没有任何动作，合同、账单、退租全靠线下。做完你会发现自己写了个“房源展示App”，不是租赁系统。
1.1 业务角色不是三个，是五个
表面上看，房屋租赁系统就是租客端、房东端、管理后台。但落到真实业务里，你要拆得更细。
- 租客端：搜索房源、浏览详情、收藏对比、预约看房、发起签约、查看账单、在线缴费。
- 房东端：房源管理（上架/下架/编辑）、预约处理（同意/拒绝）、合同签署、账单催缴。
- 管理员/平台端：审核房源是否真实存在、处理投诉、合同备案、统计分析。
这还没算运营角色。但如果你在小程序端只做租客能用的页面，把所有管理功能全塞进一个微信公众号后台或者电脑Web后台，这项目就不算有“多端协同”的亮点。评审老师恰恰最在意这个：你的系统，能不能体现出不同角色在小程序里做不同的事。
我的做法是：小程序端同时容纳租客端和房东端，通过登录后的角色标识切换视图。同一套代码里，一个按钮在租客眼里是“立即预约”，在房东眼里是“发布房源”。管理员不进小程序，用独立管理后台处理审核和全量数据。这样既控制了开发量，又保证了“多角色”的业务闭环能被演示出来。
1.2 业务流程要跑通的不是一条线，是个循环
你单独拉一条“找房 → 看房 → 签约 → 入住”的线，那是租房广告，不是系统。系统要跑通的是循环：
房源发布 -> 平台审核 -> 前台展示 -> 租客预约 -> 房东确认 -> 线下/线上看房 -> 双方签约 -> 生成账单 -> 定期缴租 -> 合同到期 -> 退租退款 -> 房源重新上架
我项目里的核心表设计、状态字段、接口划分，全部是按这个循环走的。比如房子不是“在租”就是“已租”，这不够。你要让一间房经历过“空置中 -> 待审核 -> 展示中 -> 已预约 -> 已签约 -> 已退租待释放”的状态流转。每多一个状态位，代码确实多写一点，但你的系统在老师眼里就从“花架子”变成了“考虑过真实业务”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据表设计比写页面重要十倍
小程序页面难看可以调样式，但表结构错了，改起来是伤筋动骨。我见过有人把房源图片直接存成一个 longtext 字段，图片URL用逗号拼起来往里塞。这种设计在学生项目里常见，但一旦要做“房源主图缩略图”“图片懒加载”，你就得把整串数据拿出来split，性能差，代码也丑。
2.1 核心表别省钱，字段一次给够
我最终落地的表大概是这些，你可以直接拿去参考：
- user 用户表：除了 openid、昵称、头像，还一定要有 role 字段（租客/房东），以及 phone。小程序里手机号是要单独授权获取的，表里预留好字段，别等做到“联系房东”功能了才发现没地方存号码。
- house 房源表：title、cover_image、detail_images、province/city/district、address、rent_type（整租/合租）、price_unit、area、layout（几室几厅，建议存字符串如“3室1厅”）、orientation、floor、tags、description、status（房源状态）、landlord_id（关联房东）、audit_status。
- house_favorite 收藏表：user_id + house_id 联合唯一，再加个 create_time。
- appointment 预约看房表：house_id、tenant_id、appointment_time、status（待确认/已同意/已拒绝/已取消/已完成）、remark。
- contract 合同表：contract_no（对外展示用，别只用自增ID）、house_id、tenant_id、landlord_id、start_date、end_date、monthly_rent、deposit_amount、status（待签署/生效中/已到期/已解约）。
- bill 账单表：contract_id、bill_month、amount、status（待缴/已缴/逾期）、paid_time、payment_method。
- payment_record 缴费记录表：如果需要展示支付流水和退款记录，就别把多条记录挤在 bill 的一个字段里。
- notice 公告/消息表：接收方角色、标题、内容、是否已读。
detail_images 我建议不要直接存多张图URL，可以单独建一张 house_image 表，或者至少用 JSON 数组字段而不要用逗号拼接字符串。小程序端要做“首图大图展示、其余小图缩略”的效果，JSON 字段解析出来方便太多。
2.2 合同和账单之间的状态机，是你文档里最值钱的一张图
很多同学文档里画了实体关系图，画完就完事了，但真正体现出系统设计水平的，是状态流转图。举两个我实际用到的链路：
合同的状态：待签署 -> 生效中。生成合同的时候，租客和房东都在小程序里“确认签署”，两边都签了才变成“生效中”。到期前30天系统自动把合同标记为“即将到期”，后台可以跑定时任务来扫，也可以在租客登录时懒更新。这个状态不是简单一个字段，它决定了房源能不能被重新上架，也决定了账单要不要继续生成。
账单的状态更关键：待缴 -> 已缴，听着简单，加一个“逾期”试试。每月的1号系统根据生效中合同，自动生成一张当月账单。租客缴完，bill 状态变已缴，同时记一笔 payment_record。如果到了每月5号还没缴，状态翻成“逾期”，然后要给租客推送一条订阅消息。小程序订阅消息是一次性订阅，用户没点授权你就没法推第二次，所以我的做法是在签约完成页主动引导用户勾选“账单提醒”，把订阅消息的授权先拿到手。
建议你在项目文档里画两张大图：一张是角色用例图，一张就是上面这两个状态机。老师很喜欢问这种问题：“这个状态是怎么变的？谁触发的？”你能指着图讲清楚，比念十页需求分析都有用。
3. 技术选型的真实取舍
坦白讲，选原生小程序、uni-app 还是云开发，得看你的诉求是什么。如果你想快速出活儿，且不打算买服务器，那微信云开发是最省事的。但我更建议你搞清楚它们各自的适用场景再动手。
- 原生微信小程序 + 自建后端（Spring Boot / Node.js / thinkphp 都行）：最正统，适合答辩时被问“后端做了什么”。你能讲清楚接口设计、JWT登录态、数据库事务，这是加分项。
- uni-app 跨端：工作量最大的优势是以后可以一套代码出 H5 和 App。但要做好心理准备，uni-app 的坑也不少，尤其是微信小程序里自定义组件和原生组件混用的时候。初学者不太建议用这个来折腾。
- 微信云开发：不需要自己管服务器，数据库和存储都在微信侧。开发速度快到飞起，但有个隐患：你答辩时很难体现“后端能力”，因为云函数写起来太简单了，老师想追问并发、事务、缓存，你能讲的深度有限。
我这次的版本用的是原生小程序 + Java 后端。选它的原因是，这套源码的配套文档是面向毕设答辩的，我需要能讲清楚“客户端 -> 后端接口 -> 数据库”完整的数据流。而且房屋租赁天然适合做订单状态演示，数据表之间有外键逻辑，这些用自建后端才比较有“做系统”的感觉。
3.1 登录态和 Token 过期处理
小程序的登录不能直接拿 wx.login 返回的 code 当身份标识。你要做的是：
- wx.login 拿到 code，传给后端。
- 后端拿 code 向微信接口换取 openid。
- 后端生成自己的 session token（JWT 或随机串），存起来或直接返回给前端。
- 前端后续每个请求的 header 里带 Authorization: Bearer token。
- 后端用拦截器校验 token，解析出 userId 和 role。
有一个很经典的坑：token 过期了，前端收到 401，你弹个“请重新登录”就完事了吗？不是的。你要在小程序端封装一个 request 方法，统一处理 401，然后静默调 wx.login 重新换取 token，再重放原来的请求。不然用户在列表页滑了十分钟，突然要收藏一套房，被踢去登录页，这体验很糟糕。
另外，需要区分“登录”和“授权手机号”。用户进入小程序只是浏览，那不用强制手机号。等他下预约单、签合同的时候，再弹出手机号快捷授权填充表单。别在启动页就逼着用户授权手机号，微信审核被拒的理由里高频出现这一条。
3.2 后端接口别只做 CRUD，加几个聚合接口
一个小技巧：给你的后端加几个“看得到计算过程”的接口。比如首页的房源推荐，不要只 select * from house limit 10。你可以做一个热度排序，热度 = 浏览数 * 0.3 + 收藏数 * 0.5 + 预约数 * 0.2。这个计算值在列表接口里实时算出来，或者定时任务更新到 house 表一个 heat_score 字段里。
同理，数据看板里管理员要看的几个数字：上架房源总数、本月新增预约数、本月账单实收金额、待审核房源数。这些不要靠前端查一次列表在前端数，后端直接聚合返回。文档里也好画架构图：客户端只调用一个 dashboard 接口，背后是几张表的 group by 聚合。
4. 小程序端四个核心模块怎么落地
页面设计网上一抓一大把，你自己套一个优雅的模板就行。我只挑容易写崩、但业务价值最高的几个模块讲讲实现细节。
4.1 房源列表：筛选、搜索、分页要做好
列表页是租客第一眼看到的东西，市面上大多数源码的列表逻辑就是：下拉加载，分页页码递增。但用户真实操作里会用到这些：区域筛选（整个城市还是某个区）、价格区间（1000-2000）、租赁方式（整租/合租）、室厅数量、排序（最新/价格从低到高）。
我建议列表接口设计成：GET /house/list?city=杭州&district=西湖&minPrice=1000&maxPrice=2000&rentType=整租&bedroom=2&sort=price_asc&page=1&size=10。
后端不要用字符串拼接 SQL 去拼这种多条件，用 MyBatis 的动态 SQL 或者 QueryWrapper 这种条件构造器，能少写很多 if 判断。前端的话，筛选面板别在页面顶部堆一排容易挤爆的筛选条件，我更喜欢底部弹层半屏筛选的交互，点开是个抽屉，里面放条件组，这样手机上不至于一屏全是筛选框，房源信息只能露出两行。
搜索关键词也别每次 input 事件都请求后端。做 300ms 防抖，用户停下来才开始查，不然你和后端都要被流量打哭。分页还有个容易被忽略的问题：筛选条件变化时要重置 page=1，不然用户切了价格区间还在第5页，容易出一个“没有更多数据”的白屏。这个逻辑可以在每次筛选条件变化时强制 currentPage 回退并清空列表数据。
4.2 收藏与预约：不只是一次点击
收藏是一张独立的 house_favorite 表。做“收藏”按钮时，按钮图标要实时反映当前这套房源是不是已被该用户收藏。实现方案：进入房源详情页时，带上 houseId，后端查一下 favorite 表有没有 userId + houseId 这条记录，返回 isFavorite 字段。点击收藏/取消收藏调不同接口。如果列表页也要显示小红心，建议列表接口里直接返回 favoriteId 字段，已经收藏的返回记录ID，没收藏的返回 null，前端判断起来很省事。
预约看房就不是点击后弹“预约成功”那么简单了。它涉及到房东的时间安排。我的流程是：
- 租客在房源详情页点“预约看房”。
- 弹出选择预约日期和时段（比如周日上午、工作日晚间）的面板。
- 后端生成 appointment 记录，状态为待确认。
- 房东端小程序“预约管理”页面能看到这条记录，选择同意或拒绝。如果满房或已出租，房东可以拒绝并填写原因。
- 租客在“我的预约”里看到状态变化，如果被拒绝，可以改时间再约一次。
这里要特别注意：预约提交之后，租客端要能反查详情。创建预约接口返回值里最好直接返回 appointmentId，前端拿着这个ID跳到“预约详情页”或“预约成功页”，展示“已提交，等待房东确认”。不要跳完就丢状态，然后租客找不到自己到底约没约上。
4.3 账单和续租逻辑
生成账单可以在后端定时任务里打点，每个月1号凌晨扫所有“生效中”的合同，按照合同月租生成当月账单。如果你想在毕设里少做点定时任务，那可以在用户进入“账单”页面时做懒生成：如果当前月份已过半但账单还没生成，就现场生成。
账单状态变化之后要刷新合同状态。比如连续逾期超过15天，房东端可以发起“催缴”，租客端账单列表顶部置顶一条逾期横幅，我甚至做了一个逾期N天按日累计违约金的计算函数。这个函数写在文档里会给你加重不少技术含量，因为它是很多人不会主动去实现的业务规则。
退租逻辑也要设计好。合同到期前，系统给双方一个“申请退租/申请续租”的入口。房东同意退租后，合同状态变“已解约”，绑定房源的 status 要被释放回“空置中”。如果不释放，这套房源就在系统里永远“已租”了，这是很多实现里最容易被忽略的 bug。我建议把“房源释放”这一步放在后端处理合同状态变更的同一个事务里，保证合同状态和房源状态的一致性。
4.4 消息通知：别做“假通知”
做一个“我的消息”列表，里面塞几条静态数据，这种情况在学生项目里挺多的。但你认真想一想，消息列表里每一个条目都应该是系统事件触发写进去的，比如预约状态变化、账单逾期提醒、合同到期提醒。更扎实一点的做法是接入微信订阅消息。
小程序订阅消息的正确姿势是：签约成功后，弹一个授权框“接受账单提醒”，用户点了允许，后端存下用户的 openid + 模板ID的订阅关系，等到每月账单逾期时，后端调微信接口给他发一条订阅消息。一次性订阅消息只能发一条，所以建议你在关键时刻多点几次授权申请，比如预约成功页和签约成功页分别申请不同类型的提醒授权。
如果因为条件限制没法真正接微信推送，也建议把消息表设计好：message_type、biz_id、receiver_id、is_read、content、create_time。后端在处理预约状态变更、账单状态变更的时候，顺手往消息表里插一条记录，前端“消息中心”小圆点上的未读计数就有真实数据来源了。老师演示的时候点开消息列表，看到的是能跳转到对应合同页或预约页的动态数据，而不是三条固定文案，这个细节非常加分。
5. 小程序端避坑记录
小程序开发跟普通 Web 开发完全不同，以下几点如果你提前不知道，很可能在做项目时卡上两三天。
5.1 图片上传前后端都要做限制
房源图片上传，前端 wx.chooseMedia 可以选择照片，但要限制数量、大小和类型。后端接口必须要校验文件扩展名和大小，不能只信前端的限制。尤其在后端做图片存储时，最好对上传文件做重命名，别让用户上传的文件名直接落库或落盘，一方面防止路径注入，另一方面也避免中文名和特殊符号带来的存储乱码问题。
如果是用云存储，那更要注意 security 规则。不要让你的 storage 规则设成所有用户可读可写，不然别人可以遍历你的存储桶，甚至往里面传垃圾文件产生费用。
5.2 定位授权和隐私协议要提前处理
房屋租赁系统基本都有“附近房源”或者按城市筛选的功能，所以你会用 wx.getLocation。但很多同学到了 2024 年还在用旧的授权弹窗逻辑，真机一调试发现：用户拒绝过一次定位授权之后，再次调用 getLocation 永远失败，而且不再弹窗了。
原因和微信基础库的隐私协议接口有关。现在要先用 wx.getPrivacySetting 或者直接通过 wx.requirePrivacyAuthorize 来触发隐私授权弹窗，然后引导用户手动打开设置页面。你要在小程序管理后台的“用户隐私保护指引”里声明收集位置信息、手机号、相册权限，这一步没做的话，开发工具里真机调试也能跑，但审核发布的时候会被打回。
我做项目时为了避免定位权限被拒后项目变成“查不了房源”的废项目，做了一层降级逻辑：用户拒绝授权，页面提示“暂未获取定位，您可手动选择城市”，然后整个系统退化为城市选择模式，不让用户卡在必经流程上。
5.3 滚动列表的性能陷阱
房源列表页最容易卡，一个原因是房屋图片太多、太大。要注意三点：
- 图片用懒加载，小程序 image 组件自带 lazy-load 属性，直接设上。
- 列表接口做分页，每页10条就够了，别一次把50套房全查出来渲染。
- 如果一套房源详情有10张图，详情页用 swiper 展示时，要压缩图片质量，长列表的 swiper-item 不要预加载全部图片，考虑用 mode="aspectFill" 加上合适的图片裁剪宽高，避免原图直接渲染。
另外一个隐蔽的坑：在 scroll-view 里做房屋列表时，大量使用 position: sticky 的头部分类吸顶，iOS 上会出现吸顶抖动。解决方案是比较底层，但你可以直接把整个页面滚动的承载者设置成 page 本身，让筛选栏作为页面级元素的 sticky 定位，而不是放在 scroll-view 里做内部吸顶。
5.4 原生组件的层级和样式隔离
小程序里有几个原生组件天生就“高人一等”，比如 map、video、textarea、canvas。租房详情页如果放了地图组件，而你想在页面上浮一个“立即预约”的自定义按钮，旧基础库会出现按钮被地图盖住的问题。
现在基本已经支持同层渲染，但还是要小心：尽量不要在原生组件上面做 fixed 悬浮按钮，给悬浮按钮单独的页面渲染时机，或者干脆把地图放在页面偏下的位置，悬浮按钮固定在顶部导航的安全区域里，避开与地图的视觉重叠。还有，textarea 在表单页做输入框时，placeholder 会偶尔抽风层级不对，这个属于基础库老毛病，出问题第一时间先检查微信开发者工具里的“基础库版本”，很多诡异 bug 升级基础库后就莫名消失了。
6. 管理后台：你的文档和答辩的重头戏
小程序端你会写一堆页面，但到答辩的时候，老师特别爱问管理后台：你怎么审核房源？怎么管理用户？数据从哪里看？如果你没有管理后台，或者后台只用了个简单的列表，那可讲的东西会少一大截。
6.1 后台建议有四个页面
至少四个：
- 数据看板：卡片展示核心指标，比如总房源数、在租房源、本月新增用户、本月账单实收。用 ECharts 画一个折线图展示近7天预约量。这些数据由后端聚合接口提供。
- 房源审核：列表展示待审核的房源，管理员可以点开详情看图片和房东填的信息，通过或驳回。驳回要填原因，原因是会推给房东端的消息。
- 账单与合同管理：按合同号、租客手机号、状态查询。这里主要是给管理员看运营情况，做线下对账用。
- 用户管理：可以停用恶意用户。停用的逻辑是用户表的 status 字段置为禁用，登录时校验。
6.2 演示时要准备几个“后台操作 -> 小程序变化”的组合
可以设计成这样的演示链路：你在后台把一套房源驳回，房东端小程序立刻多一条“房源审核未通过”的消息，租客端搜不到这套房。或者你在后台查某个合同的账单逾期记录，点进明细，能跳转到对应租客信息。这种联动演示比单开一个后台点来点去要生动得多，它证明你的前后台是通的，而不仅仅是各自管理各自的表格。
写文档时，管理后台的用例图记得单独画一张。一般评审会关注系统能不能脱离“只有小程序”这个局限，后台加上去，整个系统的业务视角就完整了。但要把握好工作量，后台页面用常见的 Vue3 + Element Plus 搭一套即可，优先把“房源审核、账单查询、看板统计”这三个做扎实，别贪多。
7. 文档、PPT 和答辩怎么配合
源码本身是底子，但“含文档+PPT+源码”三个都到位，才算一个完整的交付。拆开讲：
- 文档（毕业设计说明书/论文），重点章节应该是需求分析、数据库设计、系统实现。别把开发文档写成用户手册。你的核心讲法应该是：“我发现了租赁业务里有哪些角色、哪些痛点，然后数据表怎么设计来支撑，核心技术难点在哪，怎么解决。”
- PPT，控制在15页以内。结构可以是：项目背景与意义、技术栈、功能模块、业务流程、数据库设计、核心代码与难点、演示截图、总结展望。每页不要塞大段文字，核心模块用截图加一两条点明设计思路。
- 源码，注释写到位，尤其是 controller 层接口的注释、表结构变更的说明。老师拿到源码第一件事是打开看目录和注释，如果你的实体类和数据库表对不上，接口和页面路径对不上，答辩体验会很差。
7.1 把“房屋租赁业务里真正的难点”准备好
老师大概率会在答辩时问你类似这些问题：
- “这套系统和58同城租房频道有什么区别？”你要回答：小程序端做了多角色分流，租客、房东各自在自己的工作台里完成租赁操作；后台有审核机制，能保证基础房源真实性；账单合同和房源状态是联动的。
- “合同状态是怎么保证一致性的？”你要回答：合同生效、解约、房源释放都在同一个后端方法的事务里，前端只负责发起状态变更请求。
- “用的人多会卡吗？怎么优化？”你不用背八股，就说两三个点：列表接口做分页 + 条件筛选索引；图片压缩和懒加载；后端查询热点字段加缓存。这就足够展现你有基本工程意识。
- “如果不考虑时间，你下一步加什么功能？”建议别说什么花里胡哨的AI推荐，就说“接入地图找房、在线电子签章、支付分免押金”。这三个都是租赁领域真实存在的方向，而且都跟微信生态的开放能力契合。
7.2 PPT演示的次序建议
一上来先放“系统架构图”和“角色用例图”，让老师30秒内知道你这套东西是什么；然后登录小程序房源列表页，演示筛选、搜索、收藏；切换成房东账号，演示预约列表审核、房源上下架；切换后台，演示数据看板和房源审核；回到小程序的“我的预约/账单页面”，展示状态变化和催缴逻辑。整个流程要像讲一个完整的故事：租客找房、约看、签约、缴费、房东管理、平台审核，一条线串下来。如果时间允许，再演示被拒绝授权、弱网提示这些异常边界处理，会显得你对细节有把控。
写在最后的个人体会
做这套房屋租赁小程序，最深的感受是：项目本身并不难，难在你有没有把业务闭环想清楚。每个表、每个接口、每个状态位的背后，都能指向一个真实场景，这才是好源码应该有的样子。我不建议只把代码跑起来就收工，你花一个晚上把合同状态流转、账单逾期触发、房源状态释放这几条链路画清楚，收获可能比写一周代码还大，因为到了答辩或者面试讲项目时，讲业务逻辑的人，永远比背页面功能的人更占优势。