Java+Vue公寓出租系统全拆解：数据库、后端、前端一网打尽

市面上这套“Java + Vue 公寓出租系统”其实非常多，但很多朋友拿到源码之后，最常见的状态是：项目能跑起来，却看不懂里面每一张表为什么这么设计、每一个接口为什么这么写。等到面试官问一句“你讲讲这个项目的权限怎么做的”、“退租流程里合同和账单怎么对账”，就答不上来了。这篇文章就把这类系统从里到外拆开讲一遍，包括数据库设计、后端分层、前端页面、环境搭建和避坑事项，尽量让拿到源码的人不仅能跑起来，还能真正讲清楚这套东西。

1. 项目定位与整体设计思路

1.1 这个系统到底解决什么问题

先说这个公寓出租系统的真实使用场景。它不是给链家、贝壳那种大型中介平台用的，而是给中小型公寓运营商、二房东、或者高校里做课程设计 / 毕业设计的学生用的。核心管理对象有几个：房源（房间）、租客、合同、租金账单、报修工单。

在没有系统之前，大家通常用 Excel 记房源、用纸质合同签约、用微信催租、用本子记报修，数据分散且容易丢失。这套系统做的事情就是把“房源信息维护 — 看房签约 — 生成合同 — 按期缴租 — 退租结算 — 报修处理”这条业务链统一管理起来。

它的核心价值不在于做了什么复杂算法，而在于把业务规则固化成系统逻辑。比如：

• 同一套房间在同一时间段不能被重复出租，系统需要在合同登记时校验房态；
• 合同到期前后要能提醒管理人员，以便安排续签或退租；
• 每次收租都要产生一条流水记录，后续统计某个楼栋的月度收入时直接按流水汇总；
• 报修单要跟着房间走，退租检查时能看到这个房间的历史维修记录。

从学习角度来看，这个项目覆盖了 Java Web 开发中最经典的技能栈：Spring Boot、MyBatis/MyBatis-Plus、MySQL、Vue、Element UI、Axios、JWT 认证。功能模块完整，数据关系清晰，非常适合用来理解一个真实管理系统是怎么从零到一搭起来的。

1.2 为什么选 Java + Vue 这套技术组合

很多人纠结：现在管理系统方案那么多，有 Python + Flask 的、有 Go + React 的，为什么这套项目通常默认用 Java + Vue？

原因其实很实在。Java（尤其 Spring Boot）在企业级管理系统中的生态是最成熟的。不是说其他语言不行，而是 Spring Boot 体系里的组件一应俱全：权限框架有 Spring Security / Shiro，ORM 有 MyBatis / JPA，API 文档有 Knife4j / Swagger，任务调度有 Quartz，消息队列、缓存、分布式锁都能找到成熟方案。公司招聘后端，Java 岗位量级也最大。对于学生或者刚转行的人来说，学这套技术栈，找工作的匹配度更高。

前端选择 Vue 而不是 React 或 Angular，主要有三点考量：

• 上手门槛相对低。Vue 的模板语法比较直观，后端开发人员临时要改前端页面也看得懂。
• 中文生态和社区资源丰富。Element UI / Element Plus 组件库的文档、教程、开源后台模板非常多，遇到问题基本都能搜到答案。
• 响应式数据绑定适合管理系统。表格、表单、弹窗这些交互用 Vue 写起来很顺手，开发效率比原生 DOM 操作高太多。

这套组合还有一个隐性的好处：网上同类开源项目的数量极大，哪怕你拿到的这份源码有 bug，也能找到大量可参考的版本，排查问题不孤单。

1.3 功能模块全景拆解

一个标准的公寓出租系统，功能模块一般可以拆成七个部分：

当然，不同版本的源码功能会有些差异，有的加了停车位管理，有的加了指纹锁密码管理，有的做了多商户支持。但骨架基本逃不出上面这些。拿到源码后第一件事，就是把它的菜单列出来，对照这些模块逐个过一遍，看哪些是完整的、哪些只是摆设。

2. 数据库设计与核心表结构

2.1 数据库设计的关键决策

我在实际看这类项目的源码时，最优先看的就是数据库脚本。数据库的设计质量基本决定了这个项目的上限。表拆得好，后面业务逻辑能写得很顺；表设计一塌糊涂，写完的代码必然是一堆硬编码判断。

一份合格的公寓出租系统数据库脚本，通常会包含这几张核心表：user、house、tenant、contract、payment_record、repair_order，以及若干关联表或字典表。我见过做得好的版本，也见过做得差的版本。做得差的典型特征是：把租客信息直接冗余在合同表里，一个房间只有一条记录，退租之后历史信息直接覆盖。这样做的结果就是财务想查“这个房间曾经租给过谁”都查不到。

而合理的设计应该遵循几个原则：

• 合同和房间分离，房间只记录当前状态，合同单独成表，通过房间 ID 关联；
• 租客和合同分离，一个租客可以有多个历史合同，避免重复录入身份证信息；
• 账单和收款流水分离，账单描述“应付多少”，流水记录“实收多少”，两者通过账单号关联，方便对账；
• 金额统一以“分”为单位存储，避免浮点数计算出现 0.1 + 0.2 = 0.30000000000000004 这种问题；
• 状态字段用 TINYINT 存储数字枚举值，而不是直接存中文字符串，例如房间状态 0=空置、1=已出租、2=维修中。

2.2 核心表结构详解

以下直接给出核心表的参考结构，大家在对照自己手里源码时，可以拿这些做基准。

用户表user：

这里password字段一定要是加密后的密文，明文密码出现在数据库里属于重大安全隐患，源码如果是明文，务必自己改掉。

房源表house：

注意这里rent_price、deposit都用bigint而不是decimal，就是因为金额以分存储。这样做索引效率更高，也不存在小数点精度问题。前端展示时除以 100 转成元即可。

租客表tenant：

合同表contract：

合同表是整个系统的核心，房源和租客通过它产生业务关系。一个合理的系统里，合同表是只增不改的，退租只是修改状态，而不是删除记录。

缴费流水表payment_record：

报修表repair_order：

2.3 表关系与索引设计注意事项

从上面的表能看出一套典型的关系模型。house和contract是一对多，tenant和contract也是一对多，contract和payment_record是一对多。实际建表时，优先在外键列上建立普通索引，不一定非要去数据库层面建物理外键约束。很多生产系统都刻意不用物理外键，因为物理外键在高并发写入时会带来额外的检查开销，并且更改数据（比如归档历史记录）时容易受约束限制。但这不意味着字段关系可以乱来，逻辑外键依然要清晰。

这里有一个非常容易被忽略的点：contract表中冗余了house_id和tenant_id，但payment_record又冗余了house_id和tenant_id。这种冗余是刻意为之的，原因是为了做按楼栋、按房间统计月收入时，不需要回查合同表，直接基于流水表聚合，查询速度会快很多，写 SQL 也会简单很多。

索引设计建议如下：

• user.username加唯一索引；
• house.building_no加普通索引，因为经常按楼栋筛选；
• contract.house_id加普通索引，用于查某房间的合同历史；
• contract.tenant_id加普通索引，用于查某租客的合同历史；
• payment_record.contract_id加普通索引，用于对账；
• payment_record.pay_time加普通索引，用于财务按月汇总；
• tenant.id_card加唯一索引，防止同一个人重复录入。

3. 后端核心实现解析

3.1 工程结构与代码分层

大多数 Java 公寓出租系统采用 Spring Boot + MyBatis/MyBatis-Plus + MySQL 的组合，工程目录结构高度相似。拿到源码后，先看几层包：controller、service、mapper、entity/domain、config、common/utils。这是一个典型的三层架构。

• controller：只负责接收参数、调用 service、返回统一结构，不写业务逻辑；
• service：承载业务规则，比如签约时的房态校验、退租时的费用结算都在这层；
• mapper：数据访问层，定义 SQL 映射接口，这一层不要出现业务判断。

还有一个细节值得注意：好项目的 controller 和 service 之间会隔着一层 DTO/VO。什么意思呢？就是User实体类可能包含password字段，但接口返回用户列表时，不应该把密码返回给前端。处理方式是定义一个UserVO，只返回id、username、realName、role这些安全字段。很多差一点的源码图省事，直接把实体类返回前端，这是安全隐患。

统一返回结构也很关键。不管成功失败，接口都应该返回一个固定格式的 JSON，例如：

{ "code": 200, "message": "操作成功", "data": {} }

前端 axios 拦截器统一判断code，如果等于 200 就走成功逻辑，否则弹出message。这样做的好处是，错误处理逻辑集中在一处，不用每个接口单独判断状态码。

3.2 认证授权模块的实现要点

登录认证这块，目前比较主流的是JWT（JSON Web Token） + 拦截器的方案，少数老旧版本还在用 Session + Cookie。我建议看源码时优先理解 JWT 方案，因为现在面试问得多，而且前后端分离场景下 JWT 比 Session 更合适。

JWT 的流程如下：

1. 用户提交用户名密码；
2. 后端核验用户名是否存在、密码是否正确；
3. 校验通过后生成一个 token，token 中携带用户 ID、角色、过期时间；
4. 后端把 token 返回给前端，前端存储在 localStorage 或 Vuex/Pinia 中；
5. 前端每次请求在请求头Authorization中带上 token；
6. 后端写一个拦截器，拦截所有需要登录的请求，校验 token 是否有效。

密码加密必须用不可逆加密算法。Spring Boot 中推荐使用BCryptPasswordEncoder，它自带盐值处理，同一个密码每次加密出来的结果都不一样，但matches方法可以验证。千万不要用 MD5 直接加密再存数据库，MD5 撞库太容易了。

下面给出典型的 JWT 工具类核心逻辑：

@Component public class JwtUtil { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; // 过期时间，单位秒 public String generateToken(Long userId, Integer role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + expire * 1000)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }

拦截器的核心逻辑是：从请求头取出 token，先判断是否存在，再解析，解析失败则直接返回 401；解析成功则把用户 ID 放入请求上下文，供后续业务使用。

3.3 房源与租客管理的业务逻辑

房源管理的难点不在于简单的增删改查，而在于状态流转的严谨性。一个房间的状态可能是空置、已租、维修、停租。新增房源默认空置；签约成功后变为已租；退租操作后变回空置；后勤报修可以临时把房间状态改成维修中，维修完成后恢复。

在真正的项目代码中，签约接口的关键步骤应该是：

1. 根据houseId查出房源，校验当前状态必须为“空置”，否则直接抛业务异常；
2. 查询该租客是否已有在履约中的合同，如果有则提示不能重复签约；
3. 创建合同记录，状态设为履约中；
4. 更新房源状态为“已租”；
5. 如果系统支持自动生成首期账单，再插入一条payment_record。

这里特别提醒一点：这些步骤必须放在同一个事务里。如果只创建合同而忘记更新房源状态，或者合同插入成功后后续步骤报错，就会造成数据不一致。Spring Boot 中，在 service 方法上加@Transactional注解即可，但很多初学者会犯一个错误：在同一个类里通过this调用带事务的方法，事务会失效。正确做法是把事务方法放到不同的 Bean 中，或者从外部调用。

租客管理相对简单一些，核心就是信息的增删改查和身份证查重。有一个实用的加分项是黑名单机制：租客有历史退租时押金纠纷记录，可以标记为黑名单；新增合同前，系统自动检查该租客是否在黑名单中，在黑名单中则提示管理员确认。虽然大部分基础版系统不做这个功能，但面试时提一句“我可以加一个黑名单校验”，会显得你对业务风险有意识。

3.4 退租与账务结算的实现思路

退租是整个系统中业务流程最复杂的环节之一，我看过的很多源码在这个功能上都做得比较粗糙，有些甚至只改一下合同状态就完事，租金结算完全没有。

一个合理的退租流程应该包含以下步骤：

1. 校验合同状态，只有“履约中”的合同才能发起退租；
2. 计算租金：从上次缴费截止日期到退租日期之间，产生的应付租金；
3. 计算押金：按合同约定全额记录，再根据房屋损坏情况、水电欠费情况做抵扣；
4. 生成退租结算单，展示应付、实付、押金、抵扣、应退金额；
5. 确认结算完成后，关闭合同（状态改为已退租）；
6. 更新房源状态为空置，同时把房间里的电表读数、水表读数归档到合同记录中。

这里你可能会发现，业务版本越完善，需要的表就越多。基础版可能只改状态，好一点的版本会加一张checkout_record结算表。所以拿到源码后，如果发现退租功能只有一个“删除合同”，说明这份源码的业务完成度并不高，需要自己动手补全。

4. 前端 Vue 实现拆解

4.1 前端工程化基础

前端部分基本是标准的 Vue 工程。技术栈一般是Vue 2 + Element UI或Vue 3 + Element Plus，配合Vue Router、Pinia/Vuex、Axios。拿到源码后，先看package.json里的依赖，就能确定这是哪个版本组合。

不管是 Vue 2 还是 Vue 3，工程目录都有共同点：

• src/views：页面组件，一个路由对应一个页面；
• src/components：公共组件，比如上传组件、搜索栏组件；
• src/router：路由配置；
• src/store：全局状态管理，登录信息、Token 一般放这里；
• src/utils/request.js：封装好的 axios 实例；
• src/api：按模块拆分的接口请求函数。

这里有一个容易踩坑的地方：如果你的源码是 Vue 2 + Element UI，而你的 Vue 版本是 Vue 3，直接把 Element UI 装上去是不行的，必须用 Element Plus，因为 Element UI 底层依赖 Vue 2 的插件机制。装依赖之前，先确认清楚版本，不要盲目执行 npm install。

模块化是 Vue 项目的核心优势。以房源管理页为例，理想的分包方式是：

• house.vue：列表页，负责搜索条件和表格展示；
• house-form.vue：新增/编辑弹窗表单；
• house-detail.vue：房间详情抽屉，展示租客信息、历史合同、缴费记录。

每个模块之间通过props和events或者Pinia通信，不让页面之间互相引得太深。

4.2 核心页面与路由设计

路由建议采用“整体布局 + 嵌套路由”的方式。以管理后台为例，最外层的布局组件只负责渲染侧边栏和顶栏，内部通过<router-view />渲染二级页面。路由权限一般由两种方式控制：

• 后端返回菜单列表，前端动态添加路由：管理员登录后，后端返回他能访问的菜单，前端用router.addRoute()动态注册。这个方案灵活但实现复杂，很多基础版源码没做。
• 前端路由表固定，登录后按钮级权限用 v-if 控制：所有页面都在路由表里，只是页面上的“新增”、“删除”按钮根据角色判断显隐。这个方案简单直接，适合小型系统。

登录页也是必须重点看的页面。一个规范的前端登录流程是这样的：

1. 用户输入用户名密码；
2. 前端调用login接口；
3. 后端返回 token 和用户信息；
4. 前端把 token 存到localStorage，并同步到 Pinia store；
5. 路由跳转到首页，同时根据用户角色渲染对应的菜单。

前面提到的 axios 封装，建议统一做三件事：请求时从 store 中取出 token 放入请求头；响应时统一判断业务状态码；遇到 401 时自动清除本地登录信息并跳转回登录页。这三个操作集中写，全站的请求处理都会干净很多。

4.3 前后端联调接口与跨域处理

前后端分离项目必然遇到跨域问题。本地开发阶段，常见方案是两种：

方案一：前端代理（推荐，只影响开发环境）

在vue.config.js中配置：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } } };

这样做的好处是：前端请求/api/user/list，开发服务器会把请求转发到http://localhost:8081/user/list，浏览器的地址栏看起来依然是同源，不会产生跨域报错。这个方案只在开发环境生效，打包上线之后是由 Nginx 来做统一的反向代理，原理类似。

方案二：后端开启 CORS

Spring Boot 中写一个配置类，允许指定来源跨域：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

这个方案实现简单，但生产环境一般不建议全放开，最好只允许指定的前端域名。

调试接口还有一个非常实用的工具推荐：Apifox 或 Postman。先把后端接口逐个调试一遍，确认数据格式没问题，再去看前端页面。很多新手遇到前端表格没数据，第一反应是改代码，实际原因往往是后端接口报错或者返回格式与前端预期不一致。

4.4 后端server启动的完整步骤

我以实际环境中比较常用的启动流程来说明。假设源码下载后，后端工程是一个标准的 Maven 项目，前端工程是 Vue 项目。按下面顺序来做，成功率最高：

第一步：导入数据库

在 MySQL 中新建一个数据库，例如apartment_system，然后把源码中附带的.sql文件导入：

mysql -u root -p apartment_system < apartment.sql

导入完成后，用SHOW TABLES;确认表是否齐全。很多时候源码的 SQL 脚本只是部分表，缺失的表会在系统启动后报“Table 'xxx' doesn't exist”，这一步就能提前发现。

第二步：配置数据库连接

在后端application.yml或application.properties中修改数据库连接信息：

spring: datasource: url: jdbc:mysql://localhost:3306/apartment_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这里有个高频坑：MySQL 8.x 的驱动类是com.mysql.cj.jdbc.Driver，MySQL 5.x 是com.mysql.jdbc.Driver。如果你本机 MySQL 8.0 对应源码里的驱动是旧的 5.x 驱动，需要统一替换成 8.x 的版本，并在 pom.xml 中把 mysql-connector-java 的版本升级到匹配的版本。

第三步：启动后端服务

在项目根目录执行：

mvn spring-boot:run

或者用 IDEA 直接运行启动类。看到 Spring Boot 启动日志输出Started就算成功。

第四步：启动前端

进入前端目录：

npm install npm run serve

注意npm install如果很慢，可以配置国内镜像：

npm config set registry https://registry.npmmirror.com

第五步：联调测试

浏览器访问前端地址，默认账号密码登录，然后逐个页面点击测试。重点测试登录、房源增删改查、签约、退租这几个核心链路，记录发现的问题。

5. 常见问题与避坑指南

5.1 环境搭建与启动阶段问题

端口被占用

启动后端时出现Web server failed to start. Port 8080 was already in use，说明 8080 端口被其他进程占了。处理方法：改后端的server.port配置，改成 8081；或者前端代理目标地址同步修改。

数据库时区报错

连接 MySQL 8.x 时，控制台出现The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，解决方案是在连接 URL 上显式加serverTimezone=Asia/Shanghai，或者执行：

SET GLOBAL time_zone = '+8:00';

数据库版本不匹配

源码基于 MySQL 5.7 开发，但你本地是 MySQL 8.0 时，容易出现Auth plugin 'caching_sha2_password' cannot be loaded。解决方案有两种：一是新建一个用户并指定mysql_native_password加密方式；二是在后端 pom.xml 里把 MySQL 驱动升级到 8.x。

5.2 数据库与业务逻辑问题

中文乱码

页面新增房源后，列表里中文显示乱码。原因一般是数据库表默认字符集不是utf8mb4。解决方法是在建库时指定：

CREATE DATABASE apartment_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

已经建好库的可以执行：

ALTER TABLE house CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

金额精度异常

部分源码在计算租金时使用double或Float，累计月份多了之后会出现 0.01 元的误差。这种问题的根源是数据库和实体类字段类型不统一。建议把金额统一为Long（单位分），在后端做计算时也用Long，只在展示给前端时除以 100。例如计算三个月租金：

Long total = rentPrice * 3; // 单位分

不要用：

double total = rentPrice / 100.0 * 3;

后者会产生浮点误差，而且后续传入数据库又是一个不精确的数字。

并发下同一个房间被重复签约

如果系统没有做好校验，两个管理员同时操作同一个空置房间，都提交了签约请求，数据表里就会出现两份对应该房间且重叠时间的合同。处理方式无非两种：一是应用层加分布式锁（单机项目用synchronized+ 数据库唯一索引即可）；二是给合同表加一个(house_id, status)的联合唯一索引，但这种方式不够灵活，如果同一房间有多个历史合同就会冲突。比较好的做法是在签约事务内，使用SELECT ... FOR UPDATE锁定房源记录，等事务提交后再释放：

SELECT * FROM house WHERE id = #{houseId} FOR UPDATE;

这样第二个请求会等第一个请求的事务提交后才读取到最新的已租状态，自然校验失败。

合同到期提醒怎么实现

很多基础版源码只有合同 CRUD，没有任何提醒函数。如果要自己加，最简单的做法是写一个定时任务，数据库层面查今天到期、7天内到期、已过期但状态仍为履约中的合同列表：

SELECT * FROM contract WHERE status = 0 AND end_date <= DATE_ADD(CURDATE(), INTERVAL 7 DAY);

后端可以用@Scheduled(cron = "0 0 8 * * ?")每天八点扫描一次，把结果推给管理员。甚至可以在首页做一个弹窗提示，这是成本极低但实用性很强的加分功能。

5.3 前后端联调中的典型问题

登录成功但请求别的接口一直 401

这种问题的排查顺序是：先确认登录后是否把 token 存到了 localStorage 中；再确认 axios 请求拦截器是否从 store 中取到了 token；然后确认后端拦截器是否放行了登录接口和静态资源路径。还有一个很容易忽略的细节：token 有效期过期。很多源码默认过期时间是 2 小时，你调试到一半过期了，就会出现“刚才还能访问，现在全部 401”。可以把jwt.expire临时调大，比如604800（7天），调试完再改回来。

前端显示日期少一天

日期类型在 JSON 序列化时，因为时区设置默认是 UTC，会导致东八区的时间被当成 UTC 时间输出，前端看到的时间比数据库里少 8 小时。解决方式是在application.yml中配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

数据库连接密码带特殊字符

比如密码是abc@123，在 YAML 中如果不用引号包起来，就会被解析错误。建议数据库密码统一加上引号：

password: "abc@123"

5.4 部署上线阶段需要注意的点

本地开发跑通了，真正部署到服务器上时，通常还会踩几个坑：

• 后端打成 jar 包运行时，静态资源路径问题。如果源码用了本地文件上传（上传房屋图片、租客证件），要注意上传路径是绝对路径还是相对路径。打成 jar 包后，File的上传目录建议放到服务器指定目录，例如/data/apartment/upload/，不能依赖项目内部路径。
• 数据库连接配置不要在代码里写死。生产环境的数据库密码和开发环境不一样，建议用application-prod.yml分开配置，并把敏感信息放到环境变量中引用。
• 前端打包后，路由模式是 history 还是 hash。如果用了 history 模式，Nginx 需要配置try_files $uri $uri/ /index.html;，否则刷新页面会 404。如果不想折腾，直接改成 hash 模式最省事。
• Tomcat / Nginx 的请求体大小限制。如果上传图片接口报错413 Request Entity Too Large，默认上传文件大小和 POST 请求体大小都要调大。

6. 安全与性能优化进阶方向

6.1 基础安全加固怎么做

先说明一下，基础版源码默认只做登录，但真实项目上线前，有几个安全点是必须补上的。

接口防刷和参数校验。新建租客的接口，如果不对phone、idCard做格式校验，脏数据就会进库。建议用@Validated注解配合 Bean Validation，例如：

public class TenantDTO { @NotBlank(message = "姓名不能为空") private String name; @Pattern(regexp = "^\\d{17}[0-9Xx]$", message = "身份证格式不正确") private String idCard; @Pattern(regexp = "^1[3-9]\\d{9}$", message = "手机号格式不正确") private String phone; }

SQL 注入。如果源码中 mapper 的 SQL 是字符串拼接（${}），要立刻改成#{}参数占位符，MyBatis 的#{}是预编译传参，可以防注入。例如：

<!-- 错误写法 --> <select id="queryHouse"> SELECT * FROM house WHERE room_no = '${roomNo}' </select> <!-- 正确写法 --> <select id="queryHouse"> SELECT * FROM house WHERE room_no = #{roomNo} </select>

密码安全。前面提到过，一定要用 BCrypt 代替 MD5。如果源码里已经大量存了 MD5 密文，可以在用户首次登录时，自动升级为 BCrypt。

操作日志。对于公寓出租这种涉及钱的系统，谁在什么时候收了哪笔钱、改了什么合同，操作记录非常重要。基础版源码基本没有日志表，建议后续自己补充一张operation_log表，在修改合同、删除房源、收费登记这些敏感操作时自动记录操作人、操作内容、IP 地址。

6.2 性能优化从哪些地方入手

公寓出租系统的并发量不会特别大，一般几十个人同时使用，但以下几点会让体验差距很大：

• 列表页接口一定要分页。有些源码把全部房源一次性返回，房源达到几百条时页面表格就开始卡顿。改成 MyBatis-Plus 的分页插件，传pageNum和pageSize，返回总数和分页数据，前端配好分页组件即可。
• 查询条件加联合索引。比如房间列表经常按building_no + status筛选，就建一个(building_no, status)的联合索引。
• 批量操作的 SQL 注意性能。比如“一键生成下月所有在租房间的账单”，如果每个房间插入一条账单用循环操作数据库，房间多时耗时较高。合理做法是写一个批量插入的 SQL，一次性提交。

<insert id="batchInsertPayment"> INSERT INTO payment_record (contract_id, house_id, tenant_id, title, amount, status, create_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.contractId}, #{item.houseId}, #{item.tenantId}, #{item.title}, #{item.amount}, #{item.status}, NOW()) </foreach> </insert>

• 数据量增长后的归档机制。如果系统持续使用好几年，已退租的合同、历史缴费流水会越来越多。可以设计一张contract_history表，定期把已退租且超过一年以上的合同迁移过去，避免主表数据过厚影响日常查询性能。

6.3 从“能跑”到“能讲清楚”的方法论

最后说一个我个人的经验。很多读者手上有这份源码，可能也是从某处下载的。拿到源码之后，不要急着把它当作毕业设计直接交上去。而是按三步去消化：

第一步：画业务流程图。把“看房 — 签约 — 收租 — 退租 — 报修”这条主链路画出来，标注每一步涉及的表和状态字段。你会发现画完之后，整个数据流就清晰了。

第二步：把核心代码自己重写一遍。不需要全部重写，选两个模块就行：签约模块和退租结算模块。这两个模块最能体现业务复杂度，也是面试官最喜欢问的。

第三步：找出系统的缺陷，并尝试修复。每份源码都有毛病，比如退租不校验账单、房源删除是物理删除导致历史合同关联丢失、没有并发保护重复签约等。每修复一个，你在这个项目上的真实经验就多一分，远比自己从零写一个完整的系统更高效。

我个人在实际操作中的体会是：“会用”和“能讲清楚”之间差的是对数据表关系的理解。一个人能把每张表为什么存在、每个状态字段为什么这样设计讲明白，那项目基本就是自己的了。如果你手里这份源码目前跑不起来，也别慌，按照上面环境搭建的顺序一项一项排查，大概率就是数据库版本、时区、端口、依赖版本这几个地方的事。先把核心链路（登录、看房源、签合同、收租）跑通，其余功能模块可以边用边补。