1. 项目概述与整体设计思路做房屋租赁系统这个选题可以说踩在了微信小程序最成熟的场景上。租房是典型的高频、短决策、强本地化需求用户不想为了看几套房源专门下载一个App小程序“用完即走”的形态正好匹配这个场景。整套项目包含源码、设计文档和答辩PPT基本就是毕业设计或者课程综合训练的标准配置下面我按实际开发顺序把整个系统的设计思路和落地细节完整过一遍。1.1 为什么选微信小程序而不是App或H5先聊选型。房屋租赁系统的核心用户是两类人租客和房东。租客的特点是“临时需求、快速对比、随时可能换租”房东的特点是“发布房源、管理订单、及时沟通”。这两类人对安装成本都极其敏感如果做成App光是下载、注册、权限授权这一串流程就能劝退一大半用户。H5虽然免安装但在调用摄像头、定位、支付这些系统能力时体验明显差一截尤其在低端安卓机上H5的流畅度和稳定性很难让人满意。微信小程序则把两边的优势都占了用户通过微信扫一扫或搜索就能进入不占桌面、不用单独注册直接复用微信授权体系同时还能调用微信生态的支付、地图、订阅消息等原生能力。对开发者来说小程序前端基于WXML/WXSS语法上接近HTML/CSS后端可以完全自建接口技术门槛适中开发周期可控。这套系统最终选“小程序 独立后端API”的架构就是综合考量了这几方面的因素。1.2 系统角色与核心模块划分这套系统我按“三端一平台”来拆租客端小程序、房东端小程序同一小程序内做角色切换、后端管理API、管理后台Web页面。注意房东端和租客端不建议做成两个独立小程序否则用户需要装两个小程序体验割裂审核也麻烦。推荐做法是在一个小程序内根据用户身份动态渲染不同入口数据库里用一个role字段区分即可。功能模块上我划分为五个核心域用户域微信登录、身份注册租客/房东、个人资料维护、实名认证可选房源域房源发布、房源列表、条件筛选、房源详情、地图选点、房源上下架交易域收藏、预约看房、租赁下单、订单管理、在线支付消息域订阅消息推送预约提醒、订单状态变更、站内信管理域后台数据统计、用户管理、房源审核、订单管理、公告管理这个划分基本覆盖了一个商业租赁平台的业务闭环又不至于像贝壳、闲鱼那样复杂到无法在毕设周期内完成。把“实名认证”“在线支付”设计成可选增强项是明智的核心先把房源流转和订单状态机跑通就足以支撑系统的完整度和答辩深度。1.3 技术栈与搭架方式前端小程序我用的是原生框架没有上uni-app或Taro。原因很简单原生框架对微信官方新能力的支持最快像订阅消息、分包异步化、云开发这些特性都是原生先行而且原生代码的可读性好、报错信息直观答辩时评审老师也能直接看懂逻辑。如果你已经熟悉Vue语法上uni-app确实能提高开发效率但要注意uni-app在部分原生组件上存在兼容差异调试成本可能反而更高。后端我选择Spring Boot MyBatis Plus MySQL这套组合Java技术栈在高校和企业里都是主流资料多、排错方便。如果你更熟悉Node.js用Express或Egg做后端也没问题只要接口设计合理前端代码可以完全复用。接口设计上统一走RESTful风格返回结构固定为code/message/data三段式前端通过封装好的request方法统一拦截错误码前后端联调会顺畅很多。2. 数据库设计与核心模型数据库是系统的地基我见过太多项目死在表设计不合理上字段冗余严重、状态全靠字符串硬编码、关联关系混乱导致后续SQL写到怀疑人生。房屋租赁系统的核心数据量不大不需要夸张的分库分表设计但该有的规范一个都不能少。2.1 核心表的字段规划用户表的设计主键id、openid微信用户标识、nickname、avatar、phone、role1租客/2房东、status、create_time、update_time。关键点在于openid必须加唯一索引这是用户身份的唯一凭证。微信登录成功后拿到的code换openid再与用户表关联整个登录态就是安全的。房源表house字段相对复杂id、landlord_id关联用户表、title、description、price月租金、deposit押金、area面积、room_count几室厅、floor楼层、orientation朝向、address详细地址、latitude/longitude经纬度用于地图展示、cover_image封面图、images多图用JSON数组存、status0待审核/1上架/2下架/3已出租、view_count浏览量、create_time、update_time。价格字段建议用int类型存“分”而不是浮点数存“元”避免精度问题前端展示时除以100即可这个习惯在支付场景里尤其重要。订单表order关联用户和房源id、order_no业务订单号、user_id、house_id、type1预约看房/2租赁下单、status、amount、deposit、start_date、end_date、create_time、update_time。订单状态机是整个系统的核心逻辑下面单独展开。2.2 表关系与索引设计关系上比较直接用户一对多房源一个房东可发多套房源用户一对多订单用户与房源通过收藏表形成多对多。另外我建了browse_record浏览记录表记录用户看过的房源字段很简单id、user_id、house_id、create_time但作用不小——首页可以基于浏览记录做“猜你喜欢”的简单推荐答辩时能多一个亮点。索引不要盲目全加那是反模式。我实际只加了几个真正有用的用户表的openid唯一索引房源表的landlord_id普通索引和status索引列表页按状态过滤订单表的order_no唯一索引和user_id索引。为什么这样设计因为查询场景主要集中在“某房东的房源列表”“某用户的订单列表”“某用户的历史浏览”这些索引就是为这几个高频SQL服务的。提示房源表的经纬度字段别用double直接存推荐用decimal(10,6)保留六位小数精度约0.1米完全满足地图展示需求还能省存储空间。2.3 订单状态机的设计思路订单状态机是租赁系统的灵魂。我设计的订单状态流转如下状态值状态名说明允许的下一步状态0待支付用户下单未支付1、41已支付/待确认支付成功等待房东确认2、52已确认房东确认租赁33已完成租期结束交易完成无终态4已取消用户支付前取消或超时关闭无终态5已退款支付后退款无终态这里要特别提醒状态变更不要直接在业务代码里随手改一定要走统一的状态机校验。比如从“已支付”直接跳到“已完成”在业务上是非法的必须先经过“已确认”。我封装了一个OrderStateMachine工具类专门校验状态迁移合法性非法迁移直接抛异常。这个设计在答辩时非常加分因为评审老师最爱问“如果用户并发下单怎么办”“房东在确认前把房源下架了怎么办”。3. 核心功能实现与代码解析这一节是整个项目的实操重点。我按用户从进入到完成交易的主路径逐个拆解关键功能的实现方式和容易踩的坑。3.1 微信登录与用户信息获取先说登录。小程序端登录逻辑如下wx.login()获取临时code传给后端后端调用微信的jscode2session接口换取openid和session_key之后按自己的规则生成业务token返回给前端。前端拿到token后存到storage里后续所有请求都在header里带上这个token。这里有一个非常经典的坑很多人在登录后会调用wx.getUserProfile获取用户头像昵称但这个接口从基础库2.21.2开始已经不再返回真实头像昵称而是返回默认灰色头像和“微信用户”。如果你的项目文档里还在用wx.getUserInfo获取昵称那线上的真实表现就是所有用户都叫“微信用户”头像全是灰的。我在测试阶段就遇到过控制台输出“wx1cb4398e1413dce7”这类错误码的“获取登录后的微信用户失败”问题查证后确认这类报错绝大多数是基础库版本过低或者接口调用方式不符合新版规范。现在的正确做法是引导用户进入“编辑资料”页面使用微信提供的头像昵称填写能力——button组件的open-typechooseAvatar选头像input组件的typenickname填昵称让用户主动上传头像和填写昵称。登录态维护还有一个细节因为token有有效期用户操作几分钟后可能遇到token过期请求会返回401或特定错误码。好的做法是在前端全局request封装里统一拦截401自动调用wx.login重新换code静默更新token后重放原请求用户完全无感知。这个“静默续期”机制非常提升体验值得写进系统设计文档。3.2 房源列表与筛选条件房源列表页是租客最常访问的页面承载了筛选、排序、分页和搜索四个功能。技术上我采用“后端分页 条件组合查询”的方式前端每次滚动到底部就请求下一页数据。分页参数用page和pageSize后端返回total和records前端据此判断还有没有更多数据。筛选条件我做了区域按城市/区县、价格区间月租范围、户型几室、租赁方式整租/合租、朝向。这些条件本质上是组合查询所以后端接口接收FilterDTO对象用MyBatis Plus的LambdaQueryWrapper动态拼接条件。关键点在于空值条件的处理必须用“! null才拼条件”的判断逻辑否则用户不选价格区间时SQL里就会出现price BETWEEN 0 AND 999999这种傻查询。排序支持按“最新发布”“价格最低”“价格最高”“浏览量最高”四种本质上是orderBy字段和orderByDirection两个参数后端映射到对应字段。这里有个小细节价格排序如果直接用数据库字段遇到价格字段为null的数据会排在最前或最后体验很怪。我处理的方式是给所有房源的价格字段设置默认值0再在查询时加一个“价格大于0”的过滤条件。3.3 地图选点与定位能力房屋租赁和位置强相关房源详情页一定要展示位置地图发布房源时最好支持地图选点。小程序提供map原生组件配合wx.chooseLocation接口就能轻松实现选点。发布房源时我调用wx.chooseLocation让房东在地图上标记具体位置选完后拿到的name、address、latitude、longitude四个值存到房源表对应字段。详情页展示时用map组件加marker标记点用户在缩略图上点击后可以调起wx.openLocation唤起微信内置地图导航。这里要注意wx.chooseLocation和wx.openLocation都需要在app.json中声明permission字段且小程序管理后台需配置位置接口权限否则真机一调用就直接fail报错信息通常是“getLocation:fail the api need to be declared in the requiredPrivateInfos field in app.json”。这个错误在真机测试阶段出现过不止一次切记提前在app.json里把requiredPrivateInfos声明好。3.4 支付流程与订单状态联动如果要做在线支付需要微信商户号个人开发者资质往往申请不下来所以这个模块很多毕设项目选择做成模拟支付。我建议项目里同时保留两种模式一是mockPay方法模拟支付延迟1.5秒后回调成功二是真实微信支付接入的封装通过配置项切换。答辩演示环境没有支付能力就跑mock老师追问时再讲清楚真实支付的完整流程商户号申请、统一下单、编签、wx.requestPayment调起收银台、回调验签、订单状态更新。真实支付的时序是这样的前端点击“去支付”→ 后端根据订单号调微信支付统一下单接口 → 拿到prepay_id并生成支付参数 → 前端调wx.requestPayment唤起收银台 → 用户支付成功 → 微信服务器异步通知后端回调地址 → 后端验签并更新订单状态为已支付 → 前端通过轮询或订阅消息通知用户支付结果。注意回调地址必须是公网可访问的HTTPS地址本地调试可以用内网穿透辅助但正式演示前建议部署到云服务器上跑一套完整环境。3.5 顶部导航栏与页面适配细节顶部导航栏是看起来不起眼但容易出问题的地方。小程序默认导航栏高度在iPhone X系列和安卓机型上不一样如果页面用自定义头部就需要适配状态栏高度。获取方式wx.getSystemInfoSync().statusBarHeight拿状态栏高度再用wx.getMenuButtonBoundingClientRect()取胶囊按钮位置两者相减就是自定义导航栏内容区的高度。这套适配代码我封装成了NavBar组件写一次后续所有自定义导航栏页面都能复用。另外首页搜索框、筛选栏、TabBar这些固定元素建议用position: sticky或固定定位避免滚动时抖动。特别是带筛选条件的列表页筛选栏必须固定在顶部否则用户滑到一半想换条件还得先滚回顶部体验会很糟糕。4. 真机调试与常见问题排查写代码一时爽真机调试火葬场。把开发者工具里跑得好好的项目搬到真机上才会遇到真正的“社会的毒打”。这一节我把开发过程中高频出现的几个问题整理成排查手册全部是实战踩坑记录。4.1 真机请求报错 net::ERR_CONNECTION_RESET这是真机调试最高频的报错之一。现象是开发者工具里接口请求一切正常手机预览时请求直接失败控制台打印“failed: net::ERR_CONNECTION_RESET”或“request:fail -2:2026”。根因绝大多数是这两类第一类接口地址是http而不是https或者用了自签名证书小程序正式版强制要求HTTPS且证书必须合法第二类用本地IP加端口的方式调试后端手机和电脑不在同一局域网或者电脑防火墙拦截了手机网络请求。排查顺序建议先在真机上打开“不校验合法域名”的调试模式请求通了就是域名证书问题还不同就把后端接口地址改成电脑的局域网IP如192.168.x.x确认手机和电脑连同一个WiFi再不通就临时关掉防火墙试一下。我项目里反复出现这个错误时最后定位到是无线路由器开启了“AP隔离”手机和电脑虽然连同一个WiFi但彼此无法通信换成手机热点给电脑共享才解决。4.2 登录态失效与获取用户信息失败“获取登录后的微信用户失败”这类问题在开发环境容易被掩盖因为开发者工具默认基础库是最新版本但真机上的微信基础库版本参差不齐。真机如果基础库版本过低不支持你用的API调用就会失败控制台会打印一堆错误码一开始很难看懂。正确排查思路是先看控制台的错误码再去微信官方文档查该API的“基础库最低版本”如果是版本问题用wx.getSystemInfoSync判断用户基础库版本做兼容降级处理。另外新版接口建议都用异步Promise风格调用不要再使用wx.getUserInfo这种渐被废弃的写法。把头像昵称填写能力、手机号获取能力都按官方最新规范实现不仅少报错答辩时讲起来也更有说服力。4.3 分包大小限制与图片优化小程序主包大小上限1.5MB总包不超过2MB这个限制让不少项目在开发后期突然报“上传失败”。如果你的项目用原生开发又引入大量UI库很容易超限。我的建议一是开启分包加载把房东端管理页、订单详情页等低频页面放进分包主包只保留首页、列表、详情、个人中心这些核心页面二是图片全部走云存储或OSS用URL引用而不是本地base64三是压缩静态资源代码开启压缩选项。用了分包之后还有一个“分包异步化”的知识点值得研究。默认情况下分包之间的资源不能直接相互引用但通过wx.requireAsync等方法在分包中异步加载其他分包资源可以突破这个限制。如果毕设文档里写到了“分包异步化”这个技术点评审老师会觉得你不是网上随便抄的代码而是真的踩过生产环境的坑。4.4 订阅消息推送方案怎么选房屋租赁系统里“预约成功提醒”“订单状态变更通知”这些场景都需要推送能力。微信小程序可选方案有三种订阅消息、客服消息、站内消息。其中订阅消息是主推方案用户主动订阅后才会收到一次性推送目前大多数模板只能推送一次不能无限次推送。实现订阅消息的关键步骤前端调wx.requestSubscribeMessage让用户订阅某个模板用户同意后拿到授权结果后端调用subscribeMessage.send接口下发消息。这里有个容易忽略的坑订阅授权是一次性的用户拒绝过一次之后再次调用wx.requestSubscribeMessage不会弹出授权框需要引导用户去“设置”页手动开启。很多同学不知道这个细节导致用户明明订阅了后台发送却totalCount为0、failedCount为1。如果你的项目部署在小程序云开发上云调用可以免鉴权调用订阅消息接口省去token管理麻烦。传统服务端模式下则需要先通过getAccessToken获取全局access_token再调用发送接口access_token有效期7200秒务必做缓存别每次都用code重新换取。4.5 版本更新与用户缓存问题小程序更新频率不低但用户端可能还停留在旧版本。即使发布了新版本用户下次打开时没做处理的话仍然跑旧版本缓存逻辑。我见过很多项目完全不处理更新逻辑结果用户反馈“功能点了没反应”其实是在跑旧版本代码。解决办法是用wx.getUpdateManager监听版本更新事件检测到新版本后弹窗提示用户重启应用。常见问题可能原因排查建议真机请求 net::ERR_CONNECTION_RESET域名未备案/证书不合法/网络隔离先开调试模式排除域名问题再检查局域网互通获取用户信息失败基础库版本过低或API废弃查错误码对照文档确认最低基础库版本上传失败提示包过大主包超过1.5MB开启分包、图片走云端、压缩静态资源订阅消息发送失败订阅授权已被使用或未缓存token检查授权状态保证access_token走缓存5. 项目文档与PPT配套要点标题里带了“文档PPT”说明这个项目不只是一堆代码还要能拿得出手、讲得清楚。很多同学代码写完了文档和PPT却拖到答辩前一天晚上才开始结果漏洞百出。我建议把文档和PPT当成项目的一部分边开发边积累素材这样产出质量高做的时候也轻松。5.1 需求分析文档怎么写需求文档是整套项目文档的根核心要写清楚三类内容用户画像与使用场景、功能需求清单、非功能需求。用户画像不要写“系统目标是提高租房效率”这种空话要具体到“22-35岁城市租客群体平均每天打开小程序2-3次最关心价格、位置和真实房屋照片”这种粒度。功能需求清单建议用表格呈现列清楚功能名称、功能描述、优先级、所属角色。比如“房源发布”描述是“房东填写房屋基本信息、上传多张图片、地图选点、设置租金与押金后提交待管理员审核后展示”优先级是P0核心功能所属角色是房东。这样一个表格下来评审老师一眼就能看出系统全貌。5.2 设计文档的框架与图表选择设计文档最核心的部分包括系统架构图、功能架构图、数据库ER图、核心流程时序图、接口文档。这些图不需要多花哨但一定要画得准确清晰。画图工具推荐draw.io或ProcessOn别用Word里的文本框手画方块那体验太痛苦了。接口文档我强烈建议直接用Swagger/OpenAPI规范自动生成。后端代码加注解启动项目后访问/swagger-ui就能看到完整接口列表不用手写接口文档还能保证与代码一致。如果后端不用Spring Boot用Apifox或Postman导出接口文档也可以但一定要保证和代码同步否则文档与实现“两张皮”是答辩里最尴尬的事。5.3 PPT结构与答辩演示节奏答辩PPT不需要太多页12-15页比较合适。建议结构选题背景与意义2页→ 核心技术栈1页→ 系统需求分析2页→ 系统设计数据库设计2页 接口设计1页→ 核心功能实现与截图3-4页→ 系统测试与优化1-2页→ 总结与展望1页。演示环节有个很实用的技巧先把小程序体验版二维码放进PPT边讲边演示。演示路径要有设计感从“用户注册登录”开始到“浏览房源-收藏-预约/下单-订单管理”走一遍主流程再用管理员账号演示“房源审核”和“数据统计”把整个业务闭环讲完。演示时如果网络出问题要提前准备截图兜底直接用截图讲流程别在现场反复刷新页面。5.4 答辩高频问题提前准备答辩老师最爱问的问题其实就那几个“为什么选这个课题”“系统有哪些创新点”“数据库为什么这么设计”“遇到的最大困难是什么”“系统有什么不足和改进方向”。这些问题要提前想好答案尤其是“不足和改进方向”这种看似送分实则杀人的问题——你如果答“系统没有不足”会显得很假答“系统到处都是问题”又自曝短板。我的建议是主动准备1-2个真实的、有深度的问题以及对应的改进方案。比如“当前系统未接入真实在线支付后续可以申请商户号接入微信支付V3补充押金托管和退款流程”“当前推荐逻辑比较简单后续可以基于用户浏览记录做协同过滤推荐”。这样回答既展现诚实又体现工程思维和后续规划能力。5.5 源码交付与项目部署说明拿到源码之后第一步不是急着跑起来而是先看README和配置文档。正规的项目交付都会包含环境要求JDK版本、Node版本、MySQL版本、数据库初始化脚本、前后端配置说明小程序appid、后端数据库连接、Redis配置等、启动步骤。如果这份源码的文档不够全建议自己梳理一份“部署手册”把每一步操作截图记录这对答辩演示非常有帮助。部署时我习惯把后端打成jar包放到云服务器上MySQL和Redis用云数据库或Docker部署小程序上传体验版用于演示。整套环境跑通之后记得把关键配置项单独整理成一个配置文件比如数据库账号密码、小程序appid、密钥等不要把敏感信息硬编码在代码里提交到git仓库这个习惯在团队协作或后期维护时非常加分。最后再分享一个心得做这类项目代码能力固然重要但更重要的其实是“系统思维”——从用户需求出发拆解功能从数据角度设计表结构从工程视角考虑异常和边界。把这条链路想清楚代码只是顺理成章的结果。如果你正在做类似的项目把上面每个模块按章节拆开逐块完成每天推进一点一个月内跑通第一版是完全可行的。等整套系统跑通、文档写好、PPT做完你会发现自己对“从0到1做一款产品”这件事的理解比写一万行代码都深。