简介：围绕微信小程序房屋租赁管理系统的毕业设计完整资料包，面向计算机专业学生在课程设计、毕业答辩或SSM框架实践中的需求，覆盖房源管理、租房订单、账单、用户及中介角色等核心功能，实现房屋租赁业务的系统化流程。压缩包共1069个文件，大小约59.06MB，以java/vue/js源码、png/svg界面素材、sql数据库脚本、mp4视频演示为主，另有doc/txt文档与bat运行脚本，目录划分清晰。已有43人学习浏览，资源完整度较高。内含SSM后端、Vue管理后台、微信小程序前端及数据库初始化脚本，并附毕业论文与操作录屏，便于对照设计文档理解功能模块与数据库表结构；安装批处理与配置文件可帮助快速启动项目，无论是毕业设计参考还是小程序的二次开发，都能提供直接的落地支撑。
1. 房东还在用 Excel 和微信群管房？微信小程序房屋租赁系统到底解决什么问题
一个中介手上有 40 套房，房源信息躺在 Excel 里，租客在微信群里喊“水管漏了”“门锁坏了”，租金到期全靠手机闹钟和笔记本上的铅笔标记。这不是个别现象，而是中小公寓运营方的常态。基于微信小程序的房屋租赁管理系统，做的是把房源发布、租客登记、合同签署、账单生成和到期提醒全部装进一个不用下载、扫码即开的小程序里。这套系统的成本和维护门槛比 App 低一截，用户不需要安装，开放给租客后几乎没有学习成本，适合两类人：一类是被表格和群消息折腾烦的中介、二房东和公寓运营方，另一类是正在选毕业设计或外包课题、想避开常见坑的开发者。做之前有两个问题必须先想清楚：一是微信平台侧的规则约束，二是租约状态怎么建模才不会在退租时算错账。
2. 从 AppID 到后端框架：房屋租赁小程序的技术选型与最小可跑架构
2.1 前端：原生小程序还是 uni-app，按交付场景选
如果只做微信端，我建议直接上原生小程序。原生在真机调试、微信支付、订阅消息这些能力上都是最直接的，不需要等第三方框架适配。如果你的业务后续要扩展到支付宝小程序、抖音小程序，或者要打包成 Android/iOS/鸿蒙 App，那用 uni-app 更划算，同一套 Vue 语法可以多端发布，代价是部分微信专有能力要写条件编译。
前端最需要注意的不是语言本身，而是小程序的运行模型：逻辑层和渲染层是分开的，页面数据靠setData从逻辑层传到渲染层，这个操作是异步且按 JSON 序列化传输的。很多刚上手的人把setData当this.data = xxx用，一次推几百条数据，页面直接白屏，这在第 5 章会展开讲。最小可跑的项目结构大致是这样：
{ "pages": [ "pages/index/index", "pages/house/list/list", "pages/house/detail/detail", "pages/contract/list/list", "pages/user/login/login" ], "window": { "navigationBarTitleText": "租房管理", "navigationBarBackgroundColor": "#ffffff", "navigationBarTextStyle": "black" }, "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/house/list/list", "text": "房源" }, { "pagePath": "pages/user/login/login", "text": "我的" } ] } }这个配置的意图是把小程序切成三个主入口：首页放运营概览和待办事项，房源页负责房源浏览和筛选，个人页承载登录、合同列表和管理员入口。tabBar只放三个 Tab，避免把“合同管理”“账单管理”都塞进一级导航，那样在手机屏幕上会显得拥挤。
2.2 后端：Spring Boot + MySQL 是成本最低的常见组合
后端我一般推荐 Spring Boot + MyBatis-Plus + MySQL。原因是这套组合的资料密度极高，遇到问题基本都能搜到现成案例，团队招人也容易。接口统一走 RESTful JSON，小程序端用wx.request发起 HTTPS 请求。
如果做毕设或内部管理系统，也可以考虑微信云开发：不需要自己买服务器、配 HTTPS 域名，云函数直接写逻辑，云数据库自动带权限控制。但要提醒一点：云开发的项目后期如果要迁移到自建服务器，几乎等于重写后端。如果题目是“设计与实现”，通常评审会看完整的后端代码和数据库设计，这时自建后端更占优势。
后端选型还要提前定三件事：登录态用 JWT 还是 session，文件存本地还是对象存储，定时任务用什么触发。登录态我建议用 JWT，小程序端每次请求带上 token，后端拦截器统一校验。文件存储如果房源图片量大，用云存储或 OSS，不然后端服务器带宽会很紧张。定时任务常见做法是 Spring Boot 自带的@Scheduled配合cron表达式，租约到期提醒、账单生成这类任务直接用就行。
2.3 通信链路上的三个“微信规定”，决定你能跑多顺
微信小程序和普通 Web 项目最大的区别在合规约束。第一，wx.request、wx.uploadFile、wx.downloadFile的域名必须在微信公众平台配置合法域名，而且必须是 HTTPS，不能直接填 IP。开发调试阶段可以在开发者工具里勾选“不校验合法域名”，但真机体验版不勾就白屏。
第二，登录必须走wx.login获取临时 code，再由后端用 code 换 openid 和 session_key。小程序端没有 cookie 机制，不能像 Web 一样靠 session 维持登录，所以需要后端自己发 token 给前端存起来。
第三，给租客发提醒只能用订阅消息，且订阅消息是一次性的——用户每次点击“允许”只对应一次下发机会。这意味着“到期前 3 天提醒租客交租”这种功能，在用户没有主动订阅的情况下无法实现。设计业务时要让租客在签合同、下单时顺手完成订阅，这是一件影响系统体验的隐性决策。
提示：如果后端要跑在本地让小程序连，开发者工具里可以勾选“不校验合法域名”并开启本地设置，但演示时要用
http://localhost或局域网 IP，手机真机访问不到电脑的 localhost，需要把接口地址改成电脑的局域网 IP。
3. 把房源、租约和账单落成表：数据库设计与状态流转
3.1 六张核心表的设计与字段说明
房屋租赁系统的数据模型不算复杂，但容易漏表。常见的设计失误是只建“房源表”和“租客表”，合同、账单靠手写管理，结果退租的时候租金押金对不上账。我建议至少拆成六张表：用户表、房源表、房源图片表、租约表、账单表、通知记录表。
先看用户表和房源表：
CREATE TABLE `t_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid，唯一', `nickname` varchar(50) DEFAULT '' COMMENT '昵称', `phone` varchar(20) DEFAULT '' COMMENT '联系电话', `role` tinyint NOT NULL DEFAULT 0 COMMENT '0-租客 1-管理员', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1-正常 0-禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `t_house` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL COMMENT '房源标题，如XX小区3室2厅', `address` varchar(200) NOT NULL COMMENT '详细地址', `area` decimal(6,2) NOT NULL COMMENT '面积，单位平米', `rent` decimal(10,2) NOT NULL COMMENT '月租金', `deposit` decimal(10,2) NOT NULL COMMENT '押金', `house_type` varchar(20) DEFAULT '' COMMENT '户型，如3室2厅', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0-空置 1-已租 2-已预订 3-下架', `landlord_id` bigint NOT NULL COMMENT '所属管理员用户id', `remark` varchar(500) DEFAULT '' COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status_rent` (`status`, `rent`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源表';这里的t_user用 openid 做唯一键是关键。微信登录换到的 openid 对每个小程序是固定的，哪怕用户换手机号，openid 不会变，所以它是天然的关联键。role字段区分管理员和租客，管理员负责发房、录合同，租客只看房和收账单。
t_house表单独拆了landlord_id，这个字段对应的是管理员的t_user.id。有人会问为什么不在房源表里直接放一个owner_name字符串——因为后续要按管理员统计业绩、按管理员分配待办，存 id 可以用 join 查出来的名字，存字符串则无法做关联统计。status字段用 0/1/2/3 四位数字表示房源状态，过渡状态“已预订”很重要，能避免两个租客同时看上同一套房。
3.2 租约表和账单表：状态设计决定退租时算不算得清账
CREATE TABLE `t_contract` ( `id` bigint NOT NULL AUTO_INCREMENT, `contract_no` varchar(32) NOT NULL COMMENT '合同编号，如Z20240601001', `house_id` bigint NOT NULL COMMENT '房源id', `tenant_id` bigint NOT NULL COMMENT '租客用户id', `start_date` date NOT NULL COMMENT '起租日期', `end_date` date NOT NULL COMMENT '到期日期', `monthly_rent` decimal(10,2) NOT NULL COMMENT '月租金（签约时快照）', `deposit` decimal(10,2) NOT NULL COMMENT '押金', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0-生效中 1-已到期 2-已退租 3-已解约', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_contract_no` (`contract_no`), KEY `idx_house_id` (`house_id`), KEY `idx_tenant_id` (`tenant_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租约表'; CREATE TABLE `t_bill` ( `id` bigint NOT NULL AUTO_INCREMENT, `bill_no` varchar(32) NOT NULL COMMENT '账单编号', `contract_id` bigint NOT NULL COMMENT '租约id', `bill_type` tinyint NOT NULL COMMENT '1-租金 2-押金 3-水费 4-电费 5-其他', `amount` decimal(10,2) NOT NULL COMMENT '金额', `due_date` date NOT NULL COMMENT '应缴日期', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0-待支付 1-已支付 2-逾期 3-已退款', `pay_time` datetime DEFAULT NULL COMMENT '支付时间', `remark` varchar(200) DEFAULT '', PRIMARY KEY (`id`), KEY `idx_contract_id` (`contract_id`), KEY `idx_due_date` (`due_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账单表';租约表里特意保存了monthly_rent和deposit的快照值，而不是和房源表实时联动。原因是租金会变，半年后续签时可能涨了 200 块，如果账单金额直接去t_house.rent查，历史账单全都会变成新价格，对账就乱了。
账单表的status是业务逻辑最重的字段。常见做法是每月 1 号定时任务扫描生效中的租约，按start_date到end_date的月份生成租金账单；水电费则按抄表数录入，后台手动生成。逾期判定不要靠定时任务每天扫——那样改了截止日期就漏了——正确做法是每次查询账单列表时，如果due_date < 今天 且 status = 0，就标记为逾期。
3.3 查询索引与列表接口：筛选条件和分页顺序决定数据库撑不撑得住
房源列表是访问量最大的接口，筛选条件通常是区域、户型、租金范围、状态。idx_status_rent这个联合索引能覆盖大部分场景，因为列表默认按“在租状态 + 租金排序”展示。
分页建议用经典的LIMIT offset, size，数据量在几千条以内完全够用。不要一上来就搞游标分页、深度分页优化，那是几万条以后的事。但有一个细节要注意：租约列表的排序字段不是create_time，而是start_date DESC——用户关心的是当前有哪些合同在生效，而不是哪条最先录入。
我见过有人把“合同编号”设计成自增 id，打印出来的合同单号是“14”，完全没有辨识度。合作过的一个项目里，合同编号用Z + 年月日 + 三位序号，例如Z20240601001，后面客服打电话报单号，用户一听就能确认，这比一长串无意义 id 好用得多。
4. 登录、发房、催租三件事的代码实现：照着能跑的微信小程序写法
4.1 登录链路：wx.login 换取 openid，后端签发 token
小程序端登录不能直接用wx.getUserInfo拿用户信息，那是早期版本的错误做法。现在标准链路是wx.login拿 code，code 只能一次性使用，后端拿 code 调微信的code2Session接口换取 openid 和 session_key。
前端登录按钮的完整实现：
// pages/user/login/login.js Page({ handleLogin() { wx.login({ success: async (res) => { if (!res.code) { wx.showToast({ title: '登录失败，请重试', icon: 'none' }); return; } // 把 code 发给自己的后端 const loginRes = await new Promise((resolve) => { wx.request({ url: 'https://api.example.com/auth/login', method: 'POST', data: { code: res.code }, success: resolve, fail: () => resolve({ data: { code: 500, msg: '网络异常' } }) }); }); // 期望后端返回 { code: 0, data: { token, role, nickname } } if (loginRes.data.code === 0) { wx.setStorageSync('token', loginRes.data.data.token); wx.setStorageSync('role', loginRes.data.data.role); wx.showToast({ title: '登录成功', icon: 'success' }); } else { wx.showToast({ title: loginRes.data.msg, icon: 'none' }); } } }); } });这个链路的关键点有三个：wx.login的 code 有效期只有 5 分钟，不能让用户填写表单后再去调；wx.request的 url 必须是已配置的合法域名，否则在真机上直接失败；后端返回的 token 必须存到本地缓存，后续所有请求的 header 里都要带上它。
后端对应的 Java 实现：
@PostMapping("/auth/login") public Result login(@RequestBody LoginRequest req) { // 1. 用 code 换 openid String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + req.getCode() + "&grant_type=authorization_code"; // 实际用 RestTemplate / OkHttp 发起请求，这里省略HTTP调用细节 WxSessionResp resp = restTemplate.getForObject(url, WxSessionResp.class); if (resp == null || resp.getOpenid() == null) { return Result.error("登录失败"); } // 2. 查用户表，不存在则自动注册 User user = userMapper.selectByOpenid(resp.getOpenid()); if (user == null) { user = new User(); user.setOpenid(resp.getOpenid()); user.setRole(0); // 默认租客 userMapper.insert(user); } // 3. 生成 JWT，包含 userId 和 role String token = JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user.getRole(), user.getNickname())); }这段代码包含系统里最核心的“自动注册”逻辑：第一次登录的用户直接建一条记录，不需要单独走注册页。实际项目中微信接口的 appid 和 secret 要配在配置中心或环境变量里，不能明文出现在代码中。
4.2 房源发布：图片上传与表单提交分开做
房源发布是最容易接口设计混乱的地方。常见错误是图片和房源信息在一个请求里提交，图片 base64 编码后塞进 JSON，后端解析巨大字符串，性能很差。正确姿势是先调wx.uploadFile逐张传图，拿到文件 id/URL 后，再把房源信息连同图片 id 列表一次提交。
// pages/house/edit/edit.js async uploadImages(filePaths) { const uploadedUrls = []; for (let i = 0; i < filePaths.length; i++) { const res = await new Promise((resolve, reject) => { wx.uploadFile({ url: 'https://api.example.com/house/upload', filePath: filePaths[i], name: 'file', header: { Authorization: `Bearer ${wx.getStorageSync('token')}` }, success: resolve, fail: reject }); }); // 后端返回 { code: 0, data: { url: 'https://.../xxx.jpg' } } const data = JSON.parse(res.data); if (data.code === 0) { uploadedUrls.push(data.data.url); } } return uploadedUrls; }这里有一个不能偷懒的点：wx.uploadFile的返回值是字符串，不是对象，必须手动JSON.parse。很多项目挂就挂在忘了解析。后端接口接收MultipartFile，保存到本地磁盘或 OSS，再返回可访问的 URL。
wx.uploadFile的name字段必须和后端@RequestParam("file")的参数名一致，否则后端收不到文件。文件大小限制在微信侧默认单次上传不能超过 10MB，房源图片通常控制在 1MB 以内，前端可以先wx.compressImage压缩再上传，省流量也省后端带宽。
房源信息提交用普通表单就行，注意必填校验放在前后端各做一次，前端防手滑，后端防绕过小程序直接调接口。
4.3 账单生成与订阅消息：定时任务和一次性订阅的组合
账单生成我见过两种方案。方案 A 是在租约创建时就把未来所有月份的账单全部生成，优点是查询快、逻辑简单，缺点是改租约日期时旧账单要批量改。方案 B 是每月 1 号定时生成当月账单，灵活，但对定时任务的稳定性有要求。我一般推荐方案 B，配合@Scheduled每月的0 0 1 * * ?执行一次。
@Component public class BillGenerateTask { @Scheduled(cron = "0 0 1 * * ?") // 每月1号凌晨1点执行 public void generateMonthlyBills() { List<Contract> contracts = contractMapper.selectActive(); // status=0 AND end_date >= 今天 for (Contract contract : contracts) { Bill exist = billMapper.selectByContractAndMonth( contract.getId(), YearMonth.now()); if (exist != null) continue; // 防止重复生成 Bill bill = new Bill(); bill.setContractId(contract.getId()); bill.setAmount(contract.getMonthlyRent()); bill.setBillType(1); // 租金 bill.setDueDate(LocalDate.now().plusDays(5)); // 5天内交租 bill.setStatus(0); billMapper.insert(bill); } } }这个定时任务的核心经验是“幂等判断”：同一个合同同一个月份不允许生成两条账单。没有这个判断，定时任务被手动触发两次就会产生重复账单，租客看到两笔待支付，体验直接崩了。
订阅消息的发送必须由用户主动触发授权。常见做法是：租客在签约成功页点击“开启缴费提醒”按钮后，后端保存用户的订阅授权记录；账单生成时，后端检查该用户是否有可用授权，有则调subscribeMessage.send。注意订阅消息每天有次数限制，测试阶段经常触发 43101 错误（用户拒绝授权），生产环境一定要做失败日志。
4.4 租客看房流程：分页加载和状态筛选的配合
租客端房源列表的核心性能瓶颈在setData。正确写法是分页拉取，每页 20 条，onReachBottom触底加载下一页。列表页的筛选组件建议用单选框承载“区域”“户型”“租金区间”，搜索框做模糊匹配小区名。
分页接口设计时，前端传pageNum和pageSize，后端返回{ total, list }。小程序端第一次进入页面加载第一页，下拉刷新时重置页码重新拉取。这里最容易被忽略的是页面onUnload时要清除加载状态，否则页面返回再进入时会出现旧数据闪烁。
5. 上线必踩的 5 个坑：从域名白名单到 setData 卡顿的排查手册
5.1 真机预览白屏、request 全部失败：request:fail url not in domain list
现象：开发者工具里接口调用正常，页面数据都能渲染；一点预览，真机打开后页面空白，控制台打印request:fail url not in domain list。
原因：小程序真机环境强制校验request合法域名。开发者工具勾选了“不校验合法域名”后可以绕过，但真机不认这个设置。如果后端接口是 IP 地址或者用了自签名证书，也会触发同样的问题。
解决：在微信公众平台「开发管理 → 开发设置 → 服务器域名」里配置request 合法域名，必须是 HTTPS，且证书是正规 CA 签发的。排在前面、最省事的开发期方案是：真机调试时在微信开发者工具里开启“真机调试”模式（也就是“不校验合法域名”的二维码节奏），但这只是临时方案，上线前必须配好正式域名。
5.2 开发者工具一切正常，真机登录却拿不到 openid
现象：登录按钮在开发者工具里点击后能正常跳转，换到手机预览就一直停在登录页，后端日志里根本没有收到/auth/login请求，或者收到了但 openid 为空。
原因：这是开发者工具和真机的差异。开发者工具的wx.login会返回一个模拟 code，后端拿这个 code 调code2Session也能成功，因为它走的是开发者工具自己的模拟逻辑。真机上如果填的是测试号 AppID，或者 AppID 没有关联到正确的密钥，code 就会失效。
解决：第一，确认小程序后台的 AppID 和代码里的 appid 完全一致；第二，真机预览不要用测试号，用开发版/体验版对应的正式 AppID；第三，后端日志把 code2Session 接口的原始返回打出来，看是40013（appid 错误）还是40163（code 已使用），错误码比猜原因高效得多。
5.3 房源图片传上去了，页面里却裂图一堆
现象：后台传图片显示成功，打开房源详情页，图片一半能显示，一半裂图；有的房子图片是灰的，点开也加载不出来。
原因：wx.uploadFile传文件用的是 uploadFile 合法域名，但页面里<image>标签加载图片走的是 downloadFile 合法域名。很多项目只配了 request 和 uploadFile，漏配了 downloadFile，导致真机上图片无法加载。如果图片存在本地服务器且走 HTTP，也会被拦。
解决：在服务器域名配置里补上downloadFile 合法域名。如果图片使用的是云存储 CDN 地址，也要确认 CDN 域名已加白名单。另一个自查项是图片 URL 是不是后端拼接错了——http://localhost:8080/upload/1.jpg这种地址在小程序真机上永远打不开，要换成公网可访问地址。
5.4 订阅消息发送失败：报错 errCode 43101
现象：后台点“发送提醒”按钮，接口返回成功，但租客收不到任何消息。查订阅消息记录，发现errcode为43101。
原因：43101 是“用户拒绝订阅消息授权”。小程序订阅消息是一次性授权，用户每次点击“允许”只代表当次有效；如果用户之前点了“总是保持以上选择，不再询问”并且选了拒绝，后续就无法再弹窗。另一个原因可能是在wx.requestSubscribeMessage里传的模板 ID 和后台subscribeMessage.send用的模板 ID 不是同一个。
解决：把订阅引导放在业务强相关的位置，比如租客提交“立即签约”按钮时，同时弹出订阅授权，这时候用户最容易同意。发送前在服务端记录该用户是否还有剩余授权次数，用完就不调发送接口，避免大量 43101 告警。调试阶段可以用测试模板，但上线前必须换成正式模板 ID，否则直接发送失败。
5.5 setData 一次塞 500 条房源，页面白屏卡顿
现象：房源列表接口一次返回全部房源，小程序端setData后页面白屏，滚动和点击退出都没响应；有的页面能显示但滑动掉帧。
原因：setData是逻辑层到渲染层的全量数据推送，数据量越大序列化时间越长。500 条房源加上图片 URL 和描述，JSON 体积可能到 200KB 以上，渲染层一次接不住，直接卡死。
解决：接口改成强制分页，每页 20 条，onReachBottom时追加下一页。如果数据量仍然大，列表页只渲染房源标题、首图缩略图和租金，详情页再请求完整字段。setData的优化原则是“一次只传当前页要显示的字段”，永远不要把整个对象倒进页面。
提示：翻车最多的永远是环境问题，不是代码问题。遇到诡异现象，先确认三个版本：微信开发者工具的版本、基础库版本、后端运行的代码分支。三个版本串了，什么问题都可能出现。
6. 上线前按这套清单过一遍：验收、压测与业务闭环检查
上线前我会花一整天走一遍全流程验收，重点不是功能有没有，而是“业务闭环”。租房管理系统的闭环是什么？是房源上架 → 租客看房 → 签合同 → 生成账单 → 收租金 → 到期退租 → 释放房源为“空置”。这条链路有一个环节断了，整个系统就只是摆设。
第一个必验场景是“退租再租”。A 租客合同到期后，管理员把租约状态改为“已退租”，房源状态自动从“已租”变“空置”，然后 B 租客可以签约。这个流程设计时容易漏掉“退租时是否生成押金账单”和“已租状态房源不可再签约”两个约束，验一次就能暴露。
第二个必验场景是“跨月账单”。现在时间是 6 月 28 日，新建一份 7 月 1 日起租的合同，定时任务在 7 月 1 日凌晨跑完后，账单是否正确生成、租客能不能在小程序里看到。建议手动把服务器时钟临时改到月底，或直接调一次任务的方法验证幂等性。
第三个必验场景是“权限越权”。普通租客能不能调用管理员接口？如果你用的是 JWT，后端拦截器有没有校验role字段？租客 A 能不能把合同编号改成租客 B 的合同编号去查详情？这几个问题靠前端隐藏入口是挡不住的，必须后端加权限判断。
我做这类系统有一个习惯：先把租约状态流转图画在纸上，状态节点写清楚“由哪个角色、在什么条件下、改成哪个状态”，再动数据库设计。状态机画清楚了，后面的接口和页面都只是搬运工。这个方法帮我避过很多次“上线后才发现退租逻辑没做”的尴尬，希望帮到你。
本文还有配套的精品资源，点击获取
