基于Spring Boot的大学生租房系统毕设全解析：从技术选型到答辩

1. 需求拆解与技术选型思路

1.1 课题到底在做什么：从功能清单看系统边界

每年一到毕业设计选题季，“基于Spring Boot的大学生租房系统”几乎都会出现在各个高校的选题列表里。这个题目能被反复选中，核心原因在于它踩中了几个关键点：业务场景贴近学生日常生活、功能复杂度适中、技术栈主流且就业市场认可度高。

先把这个系统的边界划清楚。大学生租房系统的核心用户是三类人：普通学生（租客）、房东（或个人二房东）、系统管理员。围绕这三类角色，系统要解决的核心问题也很明确：

• 学生找房难：需要按区域、价格、房型筛选房源，查看房屋详情、实拍图片和房东信息。
• 租房流程乱：线下的看房、签约、缴费记录容易扯皮，系统需要用状态机把“发布房源—申请看房—签约—入住—退租”这条链路管起来。
• 信息不透明：房东资质、房屋是否已出租、租期是否冲突，这些在传统租房平台上经常出现“图上没房、到店加价”的问题，系统要通过数据库约束和状态流转去规避。

再往细了拆，整个系统的功能模块大概分成四块：用户管理模块（注册、登录、身份认证、个人信息）、房源管理模块（发布、编辑、上下架、条件检索）、租房流程模块（看房申请、签约、退租）、后台管理模块（用户审核、房源审核、数据统计）。

这套功能拆出来之后，你会发现它跟市面上的商业租房平台（自如、贝壳）的核心逻辑是一致的，只是规模小得多。对毕业设计来说，这个规模刚好合适——既不是一个CRUD空壳，也不会复杂到半年做不完。

1.2 为什么选Spring Boot 2.7.18而不是3.x

技术选型这块我多说几句。网上关于Spring Boot版本的选择吵得挺厉害，尤其是Spring Boot 3.x发布之后，很多教程都在推新版本。但作为毕业设计，我强烈建议你选Spring Boot 2.7.18，这是我的核心推荐。

为什么？三个原因。

第一，JDK版本兼容性。Spring Boot 3.x强制要求JDK 17以上，而很多学校的课程教学还停留在JDK 8，实验室机器上装的是JDK 8，部分老旧的数据库驱动（比如某些学校的Oracle课程用的ojdbc6）也不兼容JDK 17。用2.7.18搭配JDK 8，是最稳的组合，不会在环境上卡壳。

第二，资料丰富程度。2.7.x是Spring Boot 2.x的最终版本，社区积累了大量踩坑案例。你遇到任何报错，搜索引擎一查基本都有答案。3.x的资料虽然也在积累，但对于一个要做半年以上、中间可能断断续续的毕业设计来说，稳定的资料库比尝鲜重要得多。

第三，跟后续课程和面试的衔接。很多学校的Java课程设计、企业级框架课程都是用Spring Boot 2.x讲的，面试时你写“熟悉Spring Boot 2.7.x”比写“了解Spring Boot 3.x新特性”更能经得起追问，因为你真的有大量实操经验。

顺带解释一下Spring Boot的自动装配原理，因为面试必问。Spring Boot核心的@SpringBootApplication注解是一个组合注解，它包含了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan。真正起作用的是@EnableAutoConfiguration，它通过AutoConfigurationImportSelector这个类去读取META-INF/spring.factories文件（2.7.x版本）或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件（3.x版本），把里面列出的所有自动配置类都加载到IoC容器中，再通过@ConditionalOnClass、@ConditionalOnProperty等条件注解判断，只实例化当前环境需要的Bean。

这么说有点抽象，我打个比方：自动配置就像一家自助餐厅，菜单上列了几十道菜，但厨师只做你选了的那几道。条件注解就是菜单上的勾选项——你引入了spring-boot-starter-web，相当于勾了“做一份Web应用”，于是相关的DispatcherServlet、Tomcat容器就自动配置出来了；你没引入MySQL驱动，那DataSource相关配置就自动跳过。

1.3 技术选型的其他细节：ORM、数据库、前端框架

确定Spring Boot之后，周边配套的技术选型同样重要。我的推荐组合是：

这里特别提醒一个点：不要一上来就堆技术。我见过不少同学把Redis、RabbitMQ、ElasticSearch一股脑全塞进系统，结果答辩时被老师问得哑口无言。毕业设计的关键不是用了多少技术，而是你清楚知道每个技术在系统里解决了什么具体问题。比如这个租房系统里，Redis可以做验证码缓存和热门房源缓存，这个我后面会讲；但如果你说不清楚“为什么这里非要用Redis，不用行不行”，那就别用，删掉它，系统依然成立。

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

2.1 从业务场景倒推：我们需要哪些数据表

数据库设计是毕业设计中最能体现“设计能力”的环节。很多同学的数据库建表就是凭感觉，想到哪建到哪，结果后面写代码时发现字段不够用，或者表之间关联关系混乱，改起来非常痛苦。

正确做法是从业务场景倒推。你把系统的核心流程走一遍：学生注册登录→搜索房源→浏览详情→提交看房申请→房东同意→线下看房→线上签约→生成合同→缴费入住→退租。每一步会产生什么数据、需要记录什么字段，把这些都列出来，表结构就自然出来了。

我的核心表清单如下：

1. 用户表（user）：承载所有角色的登录账号，通过role字段区分学生、房东、管理员。
2. 房东信息表（landlord_info）：只有房东角色才有的扩展信息（身份证号、联系电话、信用评分），与学生用户冗余在user表不同。
3. 房源表（house）：核心业务表，记录房源标题、描述、区域、地址、户型、面积、租金、押金、状态。
4. 房源图片表（house_image）：一个房源对应多张图片，独立成表方便管理和展示。
5. 收藏表（favorite）：学生收藏房源，记录用户ID和房源ID，联合唯一索引防止重复收藏。
6. 看房申请表（visit_apply）：学生提交看房申请，包含申请状态（待确认/已同意/已拒绝/已取消）。
7. 订单表（rent_order）：签约产生的订单，包含租期起止、月租金、押金、总金额、状态。
8. 合同表（contract）：订单确认后生成合同，存储合同编号、签订时间、条款内容。
9. 留言反馈表（feedback）：学生对房源或平台的留言，管理员可查看处理。

为什么把订单和合同拆成两张表？因为订单是“交易事件”，合同是“法律文件”，它们的生命周期不同。订单在支付完成前可以被取消，合同一旦生成就不允许随意修改，这份数据上的克制，就是数据库设计经验的体现。

2.2 关键表核心字段设计：房子表与订单表

拿房源表具体说一下字段设计。这是我实际用过的建表方案，关键字段都标了注释：

sql复制CREATE TABLE `house` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '房源ID',
  `landlord_id` bigint(20) NOT NULL COMMENT '房东用户ID',
  `title` varchar(100) NOT NULL COMMENT '房源标题',
  `description` text COMMENT '房源描述',
  `province` varchar(50) DEFAULT NULL COMMENT '省',
  `city` varchar(50) NOT NULL COMMENT '市',
  `district` varchar(50) NOT NULL COMMENT '区',
  `address` varchar(200) NOT NULL COMMENT '详细地址',
  `house_type` tinyint(4) NOT NULL COMMENT '户型：1-一室一厅 2-两室一厅 3-三室及以上 4-单间',
  `area` decimal(10,2) NOT NULL COMMENT '面积（平方米）',
  `rent` decimal(10,2) NOT NULL COMMENT '月租金（元）',
  `deposit` decimal(10,2) DEFAULT NULL COMMENT '押金（元）',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0-待审核 1-已上架 2-已下架 3-已出租',
  `verify_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '审核状态：0-待审核 1-通过 2-拒绝',
  `view_count` int(11) NOT NULL DEFAULT '0' COMMENT '浏览次数',
  `publish_time` datetime DEFAULT NULL COMMENT '发布时间',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_landlord_id` (`landlord_id`),
  KEY `idx_district_rent` (`district`, `rent`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源表';

有几个设计心得值得分享：

第一，状态字段用tinyint存储，不用字符串。status存0、1、2、3，配合代码里的状态枚举类使用，这样数据库层面更省空间，代码层面通过HouseStatusEnum做可读性映射。

第二，尽量建联合索引。idx_district_rent这个索引就是针对“按区域+按价格筛选房源”这个高频查询场景建的。因为系统里最频繁的操作就是用户搜索房源，搜索条件通常是“XX区+租金3000以下”，这个联合索引能显著提升查询速度。

第三，冗余了view_count浏览计数字段。不要觉得冗余就是设计不好，在特定场景下，冗余字段能减少一次表关联查询。房源列表页要显示浏览次数，如果每次列表查询都要去统计表里算COUNT(*)，数据一多性能就拉胯。直接用view_count字段，每次浏览时UPDATE house SET view_count = view_count + 1 WHERE id = ?，简单高效。

订单表的核心设计是状态机和金额字段：

sql复制CREATE TABLE `rent_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '订单ID',
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `house_id` bigint(20) NOT NULL COMMENT '房源ID',
  `tenant_id` bigint(20) NOT NULL COMMENT '租客用户ID',
  `landlord_id` bigint(20) 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 '押金',
  `total_amount` decimal(10,2) NOT NULL COMMENT '总金额（押金+租金）',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0-待支付 1-已支付 2-已取消 3-已退租 4-已完成',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_house_id` (`house_id`),
  KEY `idx_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租房订单表';

订单编号order_no我建议用“日期+随机数”生成，格式类似202606011530123456，前端展示和论文截图时比自增ID更有专业感。生成逻辑不用太复杂，yyyyMMddHHmmss加4位随机数就足够，保证数据库唯一键约束兜底就行。

2.3 表关系的底层逻辑：为什么需要这两张中间表

多对多关系的处理是数据库设计的经典问题，这个系统的收藏和看房申请就是典型场景。

收藏关系：一个学生可以收藏多个房源，一个房源可以被多个学生收藏，这是典型的多对多关系。标准的解决方案是创建中间关联表，不把收藏字段冗余在用户表或房源表里。favorite表就只存三列：id、user_id、house_id，加一个唯一联合索引uk_user_house(user_id, house_id)，这样用户在重复收藏时数据库层面就会报错，代码里捕获这个异常统一提示“您已收藏该房源”，不用多写一遍查询逻辑。

看房申请表也类似，但它除了关联关系还承载了业务状态：

这里有个设计细节：landlord_id是冗余字段，因为发起看房申请后房东要去审核，审核列表需要展示“XX房源的看房申请”，如果不冗余房东ID，就得通过house表先查房东ID，再关联rent_order表，多一次联表操作。业务上先确定“一个房源只有一个房东”，在这个前提下冗余这个字段就是安全的反范式设计。

3. 后端核心模块实现要点

3.1 项目分层架构与包结构设计

Spring Boot项目的包结构划分直接决定了代码的可读性和可维护性。我的习惯是：按功能模块分包，模块内部再按技术分层。这个系统的包结构长这样：

code复制com.example.rental
├── common          # 通用代码：统一返回结果、异常处理、工具类
│   ├── result
│   ├── exception
│   └── utils
├── config          # 配置类：MyBatis Plus配置、WebMvc配置、跨域配置
├── controller      # 控制层：接收请求、参数校验、返回结果
├── service         # 业务层：业务逻辑、事务管理
│   └── impl
├── mapper          # 数据访问层：MyBatis Plus的Mapper接口
├── entity          # 实体类：对应数据库表
├── dto             # 数据传输对象：接收前端参数
├── vo              # 视图对象：返回前端数据
└── interceptor     # 拦截器：登录校验、权限校验

Controller、Service、Mapper这三层是主链路，职责划分务必清晰：

• Controller层只做三件事：接收参数、调用Service、返回统一结果对象。绝对不允许在Controller里写业务逻辑，否则Service层就是空壳，答辩时老师一句“你的业务逻辑在哪层？”就不好答了。
• Service层是核心，业务规则、事务控制、状态流转全在这一层。
• Mapper层只管数据读写，复杂的SQL在Mapper.xml里写，简单的CRUD用MyBatis Plus内置方法。

统一返回结果类建议这样设计：

java复制@Data
public class Result<T> {
    private Integer code;    // 200成功，500失败，401未登录
    private String message;  // 提示信息
    private T data;          // 返回数据

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

统一返回结果的好处是前端可以统一处理响应，写一个HTTP拦截器判断code字段就行。另外配合全局异常处理器@RestControllerAdvice，业务代码里抛出自定义异常BusinessException，全局处理器统一捕获并包装成Result.error()返回，这样Controller层就不需要try-catch了，代码会清爽非常多。

3.2 JWT登录鉴权：不用Spring Security也能做出安全的认证

登录鉴权这块我没有用Spring Security，理由前面说过——毕业设计的核心是讲清楚“认证流程是怎么设计的”，Spring Security封装的过滤器链太深，三言两语讲不清楚，反而容易被问住。用JWT + 拦截器自己实现，逻辑透明，所有代码都是自己写的，答辩时底气足。

JWT（JSON Web Token）的核心流程是：用户登录成功后，服务端生成一个带签名的Token返回给前端，前端后续每次请求都在HTTP头部的Authorization字段带上这个Token，服务端通过拦截器解析Token、验证签名、从Token里读取用户信息。

具体步骤如下：

第一步，引入依赖：

xml复制<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>

第二步，编写JWT工具类：

java复制@Component
public class JwtUtils {
    // 实际项目中密钥要放到配置文件，用base64编码
    private static final String SECRET = Base64.getEncoder().encodeToString(
        "your-256-bit-secret-key".getBytes(StandardCharsets.UTF_8));
    private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; // 24小时

    public String generateToken(Long userId, String role) {
        Date now = new Date();
        Date expireDate = new Date(now.getTime() + EXPIRE_TIME);
        return Jwts.builder()
                .setSubject(String.valueOf(userId))
                .claim("role", role)
                .setIssuedAt(now)
                .setExpiration(expireDate)
                .signWith(Keys.hmacShaKeyFor(SECRET.getBytes()), SignatureAlgorithm.HS256)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(Keys.hmacShaKeyFor(SECRET.getBytes()))
                .build()
                .parseClaimsJws(token)
                .getBody();
    }
}

第三步，编写登录拦截器。拦截器要负责两件事：一是解析Token判断用户是否登录，二是根据接口要求判断角色权限。我们通过自定义注解@RequireRole配合拦截器实现权限控制，这个设计比硬编码判断角色要优雅得多：

java复制@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Autowired
    private JwtUtils jwtUtils;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) 
            throws Exception {
        // 放行预检请求
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        // 反射获取处理器方法上的注解
        if (handler instanceof HandlerMethod) {
            HandlerMethod handlerMethod = (HandlerMethod) handler;
            // 判断方法或类上是否标注了@PassToken注解，有则直接放行
            PassToken passToken = handlerMethod.getMethodAnnotation(PassToken.class);
            if (passToken != null) {
                return true;
            }
            String token = request.getHeader("Authorization");
            if (StringUtils.isBlank(token)) {
                throw new BusinessException(401, "未登录或登录已过期");
            }
            Claims claims;
            try {
                claims = jwtUtils.parseToken(token);
            } catch (Exception e) {
                throw new BusinessException(401, "Token无效或已过期");
            }
            Long userId = Long.valueOf(claims.getSubject());
            String role = claims.get("role", String.class);
            // 将用户信息存入ThreadLocal，方便Controller直接获取
            UserContext.set(userId, role);
            // 检查角色权限
            RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class);
            if (requireRole != null && !requireRole.value().equals(role)) {
                throw new BusinessException(403, "无权访问");
            }
            return true;
        }
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        UserContext.clear();
    }
}

这个设计里有几个细节值得注意：

• @PassToken注解用来标记不需要登录的接口（如登录接口本身、注册接口、房源列表页），避免每个接口都写放行逻辑。
• @RequireRole注解标记需要特定角色才能访问的接口，比如@RequireRole("ADMIN")标记的管理员接口、@RequireRole("LANDLORD")标记的房东发布房源接口。
• UserContext用ThreadLocal存储当前登录用户ID和角色，这样Controller和Service不需要在方法参数里层层传递用户ID，直接从UserContext.getUserId()就能拿到。这里千万记得在afterCompletion里调用clear()，否则线程池复用会导致用户数据串号。

第四步，配置拦截器注册：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Autowired
    private LoginInterceptor loginInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loginInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns("/auth/login", "/auth/register", "/doc.html", "/webjars/**", "/v3/api-docs/**");
    }
}

3.3 房源检索：MySQL索引优化与MyBatis Plus条件构造器

房源列表是系统里访问量最大的接口，检索条件的组合也很典型：用户可能按区域筛选，也可能按价格区间筛选，还可能按户型筛选。如果直接用MyBatis Plus的QueryWrapper堆条件，SQL性能在数据量上来之后会很差。

我的做法是：动态SQL + 合理的索引 + 分页插件。

首先，在Service里通过MyBatis Plus的LambdaQueryWrapper构建动态查询条件：

java复制public PageResult<HouseVO> searchHouses(HouseSearchDTO dto, int page, int size) {
    Page<House> pageParam = new Page<>(page, size);
    LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>();
    // 只查询已上架的房源
    wrapper.eq(House::getStatus, 1);
    // 区域筛选
    if (StringUtils.isNotBlank(dto.getDistrict())) {
        wrapper.eq(House::getDistrict, dto.getDistrict());
    }
    // 价格区间筛选
    if (dto.getMinRent() != null) {
        wrapper.ge(House::getRent, dto.getMinRent());
    }
    if (dto.getMaxRent() != null) {
        wrapper.le(House::getRent, dto.getMaxRent());
    }
    // 户型筛选
    if (dto.getHouseType() != null) {
        wrapper.eq(House::getHouseType, dto.getHouseType());
    }
    // 关键词搜索：标题或描述模糊查询
    if (StringUtils.isNotBlank(dto.getKeyword())) {
        wrapper.and(w -> w.like(House::getTitle, dto.getKeyword())
                .or().like(House::getDescription, dto.getKeyword()));
    }
    // 排序：默认按发布时间倒序，也可以按租金排序
    if ("price_asc".equals(dto.getSort())) {
        wrapper.orderByAsc(House::getRent);
    } else {
        wrapper.orderByDesc(House::getPublishTime);
    }
    // 分页查询
    Page<House> result = houseMapper.selectPage(pageParam, wrapper);
    // 转换成VO，补充图片等信息
    ...
}

MyBatis Plus的分页插件需要在配置类里注册：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

这里要特别提醒一个新手容易踩的坑：like查询无法走索引，当房源数量达到几万条，同时用like '%keyword%'做模糊搜索时全表扫描会很慢。毕业设计的数据量一般不会触发这个问题，但如果想体现思考深度，可以在论文里提到：对于全文搜索场景，可以引入ElasticSearch或MySQL全文索引来优化，然后给出扩展思路即可，不一定要真的实现。

至于热搜词里提到的“springboot版本太高”问题，其实指的就是Spring Boot 3.x升级后，javax.*包名换成jakarta.*，很多老教程的代码直接粘贴会编译报错。2.7.18就不会有这个烦恼，这也是我坚定推荐2.7.18的原因。

3.4 租房流程的状态机设计：从申请看房到退租的完整链路

租房流程是整个系统业务逻辑最复杂的部分，也是答辩时老师最喜欢问的地方。我用一个状态机把链路理清楚：

看房申请状态：0-待确认 → 1-已同意 → 4-已完成

这个流程里有一个必须先执行的动作：房源状态检查。当学生提交看房申请时，服务端必须校验房源状态为1-已上架，如果房源已经是3-已出租，要直接抛异常拒绝申请。这个校验放在Service层，用@Transactional事务包裹，防止并发下两个人同时申请同一套房源。

订单状态流转是核心中的核心，我设计了五个状态：

状态流转的核心代码如下：

java复制@Service
public class RentOrderServiceImpl implements RentOrderService {

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void cancelOrder(Long orderId, Long userId) {
        RentOrder order = rentOrderMapper.selectById(orderId);
        if (order == null) {
            throw new BusinessException("订单不存在");
        }
        // 校验订单归属
        if (!order.getTenantId().equals(userId)) {
            throw new BusinessException("无权操作该订单");
        }
        // 状态机校验：只有待支付状态才能取消
        if (order.getStatus() != 0) {
            throw new BusinessException("当前订单状态不允许取消");
        }
        // 更新订单状态
        order.setStatus(2);
        rentOrderMapper.updateById(order);
        // 释放房源状态：把房源从"已出租"改回"已上架"
        House house = houseMapper.selectById(order.getHouseId());
        house.setStatus(1);
        houseMapper.updateById(house);
    }
}

这个代码里有几个关键点：

第一，@Transactional(rollbackFor = Exception.class) 是事务注解的完整写法，不写rollbackFor的话，Spring 默认只在抛出RuntimeException时才回滚，捕获了Exception后事务不会回滚。这里我改了订单状态和房源状态两个表，必须保证原子性——要么都成功，要么都回滚。

第二，状态机校验必须在Service层做，不能依赖前端传参。 如果我直接setStatus(2)，前端传什么就是什么，那等于把状态流转的控制权交给了客户端。正确的做法是先查询当前状态，判断是否允许流转到目标状态，不允许就抛异常。这也是面试高频考点“如何设计状态机”。

第三，房源状态的联动更新。 订单取消时，房源状态要从3-已出租改回1-已上架；订单支付成功时，房源状态要改成3-已出租。这种跨表联动操作是事务的典型应用场景。

关于事务失效，我遇到过几个经典场景，这里一起列出来提醒大家：

• 在同一个类内部通过this调用另一个@Transactional方法，事务会失效。因为Spring的事务是通过AOP代理实现的，this调用不会经过代理对象。
• @Transactional只对public方法生效，private方法加了注解也没用。
• 方法被final修饰时事务失效，因为CGLIB代理无法继承final类/方法。
• 数据库表必须是InnoDB引擎，MyISAM不支持事务。

3.5 Redis缓存热点数据：验证码与房源浏览数

租房系统里有两个很适合用Redis的场景：短信验证码存储和房源浏览数统计。虽然毕业设计通常不要求集成Redis，但我强烈建议加上，理由有两个：一是给论文增加“性能优化”的章节素材，二是面试时能讲出一个真实的应用场景。

注册接口的验证码逻辑：

java复制@Service
public class AuthServiceImpl implements AuthService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public void sendVerifyCode(String email) {
        // 生成6位随机验证码
        String code = String.valueOf((int) ((Math.random() * 9 + 1) * 100000));
        // 存Redis，5分钟过期
        redisTemplate.opsForValue().set("verify:code:" + email, code, 5, TimeUnit.MINUTES);
        // 调用邮件服务发送验证码
        mailService.sendCode(email, code);
    }

    public void register(String email, String code, String password) {
        // 从Redis获取验证码
        String cachedCode = redisTemplate.opsForValue().get("verify:code:" + email);
        if (cachedCode == null || !cachedCode.equals(code)) {
            throw new BusinessException("验证码错误或已过期");
        }
        // 验证通过后删除验证码，防止重复使用
        redisTemplate.delete("verify:code:" + email);
        // 创建用户...
    }
}

Redis在这个场景解决的问题是：验证码的过期时间由Redis的TTL来管理，服务重启不会丢失（对比内存Map），而且可以方便地设置5分钟有效期。如果不用Redis，用数据库存验证码的话，每次校验都要查库、还要定时清理过期数据，麻烦得多。

房源浏览数的处理也值得一提。直接在house表上执行UPDATE house SET view_count = view_count + 1 WHERE id = ?在高并发下有行锁竞争，但毕业设计不需要这个量级。更合理的方案是先用Redis的INCR命令原子自增，然后定时批量同步到数据库：

java复制public void incrViewCount(Long houseId) {
    redisTemplate.opsForValue().increment("house:view:" + houseId);
}

@Scheduled(fixedDelay = 60000)  // 每60秒同步一次
public void syncViewCountToDB() {
    // 从Redis读取所有的浏览数增量，更新到数据库
    Set<String> keys = redisTemplate.keys("house:view:*");
    if (keys != null) {
        for (String key : keys) {
            Long houseId = Long.valueOf(key.replace("house:view:", ""));
            Integer count = Integer.valueOf(redisTemplate.opsForValue().get(key));
            houseMapper.updateViewCount(houseId, count);
            redisTemplate.delete(key);
        }
    }
}

这个方案在论文里可以写成“Redis热点数据缓存设计”，加上一张流程图，说是性能优化亮点，但代码量其实不大，性价比很高。

4. 前端页面与前后端联调的关键细节

4.1 Vue 3 + Element Plus搭建用户端核心页面

前端部分我用的是Vue 3的组合式API加Element Plus组件库。前后端分离模式下，前端项目的目标不是炫技，而是把核心页面做完整、能正常联调。租房系统的前端页面核心有：首页、房源列表页、房源详情页、用户中心（收藏、看房申请、订单）、后台管理页。

前端项目的目录结构：

code复制src
├── api              # 接口请求封装
│   ├── auth.js
│   ├── house.js
│   └── order.js
├── assets           # 静态资源
├── components       # 公共组件
├── router           # 路由配置
├── store            # Pinia状态管理
├── utils            # 工具函数
│   └── request.js   # axios封装
└── views            # 页面组件
    ├── Home.vue
    ├── house
    │   ├── HouseList.vue
    │   └── HouseDetail.vue
    └── user
        ├── Login.vue
        └── Center.vue

axios封装是联调阶段最关键的文件，统一处理Token注入和错误拦截：

javascript复制// utils/request.js
import axios from 'axios';
import { ElMessage } from 'element-plus';
import router from '../router';

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
});

// 请求拦截器：自动携带Token
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers.Authorization = token;
  }
  return config;
});

// 响应拦截器：统一处理错误
request.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求失败');
      if (res.code === 401) {
        // 登录过期，跳转登录页
        localStorage.removeItem('token');
        router.push('/login');
      }
      return Promise.reject(new Error(res.message));
    }
    return res.data;
  },
  error => {
    ElMessage.error('网络异常，请稍后重试');
    return Promise.reject(error);
  }
);

export default request;

前后端分离的最大坑就是跨域问题。 开发环境下，前端运行在Vite的5173端口，后端运行在8080端口，直接请求必然触发CORS跨域。解决办法有两个：

• 后端配置CORS（我推荐用WebMvcConfigurer统一配置）：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

• 前端配置Vite代理：在vite.config.js里配置server.proxy，把/api前缀的请求转发到后端8080端口。这个方案在部署时更灵活，生产环境用Nginx反向代理即可。

我实际用的是Vite代理方案，因为生产部署时Nginx配置一个/api转发就行，前后端都省心。

4.2 后台管理页面的权限控制与数据统计

后台管理页面是区分“普通项目”和“完整毕业设计”的一个分水岭。如果你只做了用户端功能，缺少管理后台，答辩时老师会觉得你少了一半工作量。

管理后台的核心功能有三个：用户管理（查看用户列表、禁用违规账号）、房源审核（审核房东发布的房源、下架违规房源）、数据统计（房源数量、订单数量、用户数量的统计图表）。

权限控制上，前端需要根据登录用户的角色动态渲染菜单。我的做法是在路由的meta字段里标记需要的角色，然后在路由守卫里做判断：

javascript复制// router/index.js
const routes = [
  {
    path: '/admin',
    component: AdminLayout,
    meta: { requiresAuth: true, role: 'ADMIN' },
    children: [
      { path: 'house-audit', component: HouseAudit },
      { path: 'user-manage', component: UserManage },
      { path: 'statistics', component: Statistics }
    ]
  }
];

// 全局路由守卫
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  const role = localStorage.getItem('role');
  if (to.meta.requiresAuth && !token) {
    next('/login');
  } else if (to.meta.role && to.meta.role !== role) {
    next('/403');
  } else {
    next();
  }
});

数据统计页可以用ECharts做一个柱状图展示近7天新增订单量。这个界面做出来之后截图放到论文里，效果非常加分。

4.3 前后端联调中的接口规范与常见报错

联调阶段我归纳了几个最容易踩的坑，每一个都对应一个典型报错：

第一，404且控制台提示“没有匹配的HTTP方法”。 这种情况基本是请求方式不匹配。比如后端接口只写了@GetMapping，前端却用axios.post请求，Spring会返回405或404。排查方法很简单：打开浏览器开发者工具的Network面板，看请求方法是GET还是POST，和后端Controller注解一一对应。

第二，后端报HttpMessageNotReadableException: JSON parse error。 前端提交的JSON字段名和后端实体类的属性名对不上。比如前端传houseType，后端实体类属性叫type，反序列化时就出错了。排查时先在浏览器Network面板看请求负载，确认前端payload的key，然后对应检查DTO的字段名。特别要留意前端用下划线命名（house_type）而后端用驼峰命名（houseType）的问题。

第三，后端返回的日期格式前端解析不了。 前端拿到"2026-06-01T12:00:00.000+00:00"这种默认序列化格式，格式化起来很麻烦。解决办法是在后端配置统一日期格式：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

第四，前后端分离部署时，前端访问/api路径报404。 这种情况检查Nginx配置，确保把/api前缀的请求转发到后端的8080端口：

nginx复制location /api/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

5. 常见问题与排查技巧实录

5.1 后端启动与数据库连接的经典报错

这些是我在实际开发和带学生做项目时遇到频率最高的报错，整理成速查表：

这里重点说第一个问题：数据库连接超时。很多同学在写application.yml时忽略了serverTimezone参数，结果本地连MySQL 8.0报时区错误。这个参数必须加上，建议直接照抄我的配置：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: 你的密码
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

allowPublicKeyRetrieval=true这个参数是MySQL 8.0连接时的常见坑，不加的话可能报Public Key Retrieval is not allowed。

5.2 Spring Boot项目中最容易翻车的事务失效场景

事务失效这个话题在热搜词里出现了，说明痛点非常普遍。我在学生代码里见过太多“方法加了@Transactional但数据还是写进去了”的案例。总结下来就三种：

场景一：同类内部调用

java复制@Service
public class OrderService {
    // 外部调用这个方法是走代理的，事务生效
    public void createOrder(OrderDTO dto) {
        // 逻辑...
        this.updateStock(dto.getHouseId());  // 这里this调用不经过代理，事务失效！
    }

    @Transactional
    public void updateStock(Long houseId) {
        // 这里即使抛异常，createOrder的事务也不会回滚 updateStock 的SQL
    }
}

解决方案有两个：把updateStock挪到另一个Service类里调用（推荐，按业务拆分Service）；或者注入自身代理：

java复制@Autowired
private OrderService self;  // 注入自身代理对象

public void createOrder(OrderDTO dto) {
    self.updateStock(dto.getHouseId());
}

场景二：异常被捕获没有抛出

java复制@Transactional
public void createOrder(OrderDTO dto) {
    try {
        // 业务逻辑
        orderMapper.insert(order);
        throw new RuntimeException("模拟失败");
    } catch (Exception e) {
        log.error("发生异常", e);
        // 这里把异常捕获了，没抛出，事务不会回滚！
    }
}

解决办法：不要捕获异常后用Log打一句忘掉，要么抛出异常，要么在catch块里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

场景三：非RuntimeException异常默认不回滚

java复制@Transactional
public void createOrder(OrderDTO dto) throws Exception {
    orderMapper.insert(order);
    throw new Exception("受检异常");  // 默认不会回滚！
}

解决办法：@Transactional(rollbackFor = Exception.class)，我在前面订单取消那段代码里就是这么写的。

5.3 循环依赖与MyBatis Plus分页失效的排查实录

循环依赖是Spring Boot面试的高频考点。场景是：OrderService需要注入HouseService，HouseService又需要注入OrderService，Spring容器在创建这两个Bean时互相等待，导致启动报错“The dependencies of some of the beans in the application context form a cycle”。

Spring Boot 2.6版本之后默认禁止循环依赖，所以2.7.18遇到循环依赖直接报错。解决思路有三个：

• 用@Lazy注解延迟加载其中一个依赖。
• 把公共逻辑抽取到第三个Service。
• 用@Autowired字段注入勉强绕过（但不推荐，不解决根本问题）。

毕业设计里出现循环依赖，根因通常是Service层职责划分不清，两个Service互相调对方的业务方法。我的建议是：如果两个Service的方法都要频繁互相调用，把它们共用逻辑抽到一个新的Service，让两个Service都依赖这个新Service。

MyBatis Plus分页失效的问题也值得单独说。现象是selectPage方法虽然返回了分页对象，但查出来的数据还是全量，total字段也不对。原因基本就是忘了注册分页插件PaginationInnerInterceptor。记住一点：MyBatis Plus的分页插件是拦截器，必须注册到MybatisPlusInterceptor里才会生效，否则selectPage只会在内存里分页。

排查技巧：在日志里打出SQL，如果看到LIMIT子句说明分页插件生效了。配置MyBatis Plus日志：

yaml复制mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

日志里能看到执行的SQL语句，无论是排查分页问题还是排查SQL写错都非常有用。这个配置开发调试时开着，生产环境记得关掉。

5.4 数据库连接数打满与慢查询优化

工作量到了一定阶段，你可能发现系统变卡了。两个最可能的原因：数据库连接数被打满、慢查询太多。

连接池配置上，HikariCP是Spring Boot默认的连接池，性能很好。如果同时有多个线程在请求数据库，而连接池默认最大连接数只有10，高峰期可能不够用。可以在配置里调大：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000

慢查询排查方面，MySQL开启了慢查询日志后，在mysql命令行执行：

sql复制SHOW VARIABLES LIKE 'slow_query_log%';

确认开启后，可以把耗时超过1秒的SQL记录下来，然后针对这些SQL做优化。最常见的优化手段就三招：加索引、避免SELECT *、把复杂的多表联查拆成多次单表查询。

这里我想特别强调一个开发习惯：在写SELECT语句时，如果只需要id、title、rent三个字段，就不要写SELECT *。虽然数据量小的时候看不出差别，但这个习惯一旦养成，对后续性能优化的帮助是巨大的。

6. 论文写作与答辩准备的加分建议

6.1 论文结构的“骨架”与“血肉”

毕业设计不只写代码，论文和答辩也是重头戏。Spring Boot租房系统这个题目对应的论文结构通常是这样组织的：

第一章 绪论：写“研究背景与意义”、“国内外研究现状”、“主要研究内容”。这里可以留到项目做完后写，因为做完之后你才知道系统里哪些模块花的心思多、哪些设计是独创的。

第二章 相关技术介绍：写Spring Boot框架、MyBatis Plus、Vue、MySQL、Redis。这里不要写成百科全书，要结合你的系统“为什么用这个技术”来写，比如写Spring Boot时强调“自动装配机制简化了项目搭建”、写Redis时强调“验证码存储和浏览量计数”。

第三章 系统需求分析：包括可行性分析（技术可行性、经济可行性、操作可行性）、功能需求分析、非功能需求分析。功能需求要配合用例图，非功能需求写性能指标（如页面响应时间小于3秒）、安全性（密码加密存储、JWT鉴权）、可维护性。

第四章 系统设计：包括系统总体架构（前后端分离架构图）、功能模块设计（模块划分与描述）、数据库设计（ER图、表结构）。数据库设计是这一章的重点，每张表的结构和设计理由都要写清楚。

第五章 系统实现：按功能模块依次展示核心代码和截图，每个模块写清楚实现思路和关键代码说明。这里注意：代码不要大段大段贴，只贴核心代码并加上注释解释即可。

第六章 系统测试：包括测试环境、功能测试用例表、性能测试结果。功能测试用例要覆盖核心流程：用户注册、房东发布房源、学生申请看房、订单生成、退租流程等。

关于画ER图和流程图，推荐用draw.io或者ProcessOn，画完导出图片插入论文即可。注意：文档里严禁用Mermaid格式的图，渲染效果差而且排版容易乱。

6.2 答辩常见问题与回答思路

答辩时老师会针对你的项目问一些问题，提前准备比现场发挥靠谱得多。

问题一：为什么选择Spring Boot而不是SSH/SSM？

回答思路：Spring Boot是Spring官方推出的快速开发框架，核心价值在于自动配置和约定优于配置。传统SSM（Spring+SpringMVC+MyBatis）需要大量XML配置，而Spring Boot通过starter依赖和自动配置类，可以快速搭建可运行的Web项目，而且内置Tomcat，部署时直接打jar包运行，开发效率和部署效率都更高。可以再补充一句自动装配的原理，比如@SpringBootApplication包含的@EnableAutoConfiguration会加载spring.factories中的自动配置类。

问题二：JWT和Session有什么区别？为什么用JWT？

回答思路：Session是服务端状态，服务端保存会话信息，客户端保存SessionId；JWT是无状态认证，Token本身携带用户信息，服务端通过验签来确认Token有效。选择JWT的原因是前后端分离架构下，后端接口需要同时服务于Web端和移动端，JWT天然适配这种场景，不需要在服务端维护SessionId和用户状态的映射关系。再补充一下JWT的组成部分（Header、Payload、Signature）和过期时间设置，回答就很完整了。

问题三：数据库表为什么这么设计？有哪些索引？

回答思路：从业务场景倒推表结构，强调反范式设计（如view_count冗余字段），强调联合索引idx_district_rent对应高频查询场景，强调唯一索引uk_order_no保证订单编号不重复。如果老师追问“索引为什么能加速查询”，要能回答B+树的数据结构特点——叶子节点存储数据记录，非叶子节点只存索引键，同一层的节点通过链表连接，范围查询效率高。

问题四：系统的并发量大概多少？如果要做高并发你的系统怎么改？

回答思路：先诚实说毕业设计系统定位是中小型应用，没有做高并发的压测。然后从架构层面给扩展思路：引入Redis缓存热点房源数据降低数据库压力；引入消息队列异步处理看房申请通知；Nginx做负载均衡；数据库做主从复制读写分离。这个回答的重点是体现你有性能优化的意识，而不是真的要去实现这些方案。

问题五：项目过程中遇到的最大的困难是什么？

回答思路：这个问题的目的是考察你解决问题的能力和学习能力。推荐讲技术性强的坑，比如“前后端联调时遇到的跨域问题”、“事务失效导致数据不一致”。回答模板：遇到了什么错误 → 我怎么排查的（看日志、看网络请求）→ 查资料找到原因 → 解决了 → 学到了什么。不要讲“需求不清楚”这种非技术问题，更不要讲“和队友吵架”这种负面内容。

6.3 项目扩展方向：从毕业设计到求职项目

如果你做完基础功能后还有余力，可以考虑几个低成本高回报的扩展点：

• 门户首页的轮播图管理：用管理后台动态配置，体现前后端交互的完整性。
• Excel导入导出：把订单列表导出成Excel，用EasyExcel实现，工作量不大但论文里能写“数据导入导出模块”。
• 密码强度校验和SM4加密存储：热搜词里提到了数据库用户密码采用SM4加密并在JasyptStringEncryptor中处理，这是一个能体现安全意识的加分项。毕业设计用Spring Security自带的BCryptPasswordEncoder即可，如果导师偏好国密算法，可以引入Hutool的SM4工具类对用户密码做加密，再配合Jasypt对配置文件里的数据库密码加密，论文里写“系统安全性设计”章节会非常充实。

最后再提醒一句，答辩前一定要把项目跑通一遍，用真实数据演示给老师看。我见过太多同学答辩现场因为数据库没启动、端口被占、代码最后改了没编译这类低级问题翻车的。毕业设计是给自己大学四年画句号的，认真对待，不要留下遗憾。