企业官网建设流程全解析

最近刚带人做完一个 springboot 租房管理系统的毕业设计，前后折腾了大概三周，从选题、搭框架到跑通核心功能，踩了不少坑，也总结了不少能直接抄作业的经验。这个题目在计算机毕设里属于典型的中等难度 Java Web 项目，既不会像纯 CRUD 那样显得工作量不够，又不会像微服务那一套那样把自己逼疯。

这个项目本质上是给房东、租客和管理员三方搭一个线上协作平台，核心就是房源管理、合同管理、账单管理、租客信息维护这几条主线。从技术角度看，SpringBoot 负责承载所有后端接口，前端配合 Vue 或者 Thymeleaf 都行，数据库用 MySQL，权限控制用 JWT 或者 Session 方案，整体架构清晰又不过度设计。无论你是准备拿它当毕设题目，还是想自己练习 SpringBoot 项目开发，这篇内容都能帮你在动手前把思路理顺。

1. 项目全貌与核心需求拆解

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

做毕设最容易犯的毛病就是一上来就堆功能，结果做了一堆没用的页面，核心业务反而没跑通。租房管理系统的本质需求其实很朴素：房东有房子要出租，租客要找房子住，中间涉及看房、签约、交租、退租这一连串流程，传统方式全靠 Excel 和聊天记录去管理，信息散乱且容易扯皮。

从实际使用场景来看，系统至少要覆盖这样几条业务线：

• 房源侧：房源信息发布、上下架、租售状态变更，基础信息包括小区、户型、面积、朝向、租金、押付方式等。
• 租客侧：租客信息建档，身份证件、联系方式、紧急联系人，以及历史租住记录。
• 合同侧：租房合同的创建、审核、到期提醒，核心字段是起止日期、租金、押金、付款周期。
• 财务侧：租金账单生成、收款记录、押金管理，以及逾期统计。
• 系统侧：用户登录注册、角色权限控制，管理员对整体数据进行查看和统计。

想明白这些业务场景之后，功能边界就清晰了。毕设答辩时老师最爱问“为什么设计这个模块”，能讲清楚它解决的是什么线下痛点，就已经成功了一半。

1.2 角色划分与权限设计思路

这个系统我建议采用三角色模型：管理员、房东、租客。不要一开始就想着搞复杂的 RBAC 权限模型，对毕设来说，基于角色的简单判断逻辑完全够用，而且更容易讲明白。

• 管理员：拥有全部数据权限，可以查看所有房源、合同、账单，管理平台用户账号。
• 房东：维护自己的房源信息，查看名下合同和收入账单，跟进租客状态。
• 租客：查看可租房源，发起租赁申请，查看自己的合同与缴费记录。

多个角色意味着登录后返回的菜单结构不同，前端要根据角色标识动态渲染路由。后端接口层面，可以通过拦截器校验登录状态，再通过自定义注解或角色判断来控制接口访问权限。这里的小技巧是：不要只在前端做按钮级隐藏，后端接口必须做二次校验，否则答辩时老师写个脚本直接调接口，你的权限体系就等于摆设。

1.3 功能优先级取舍策略

毕设时间有限，功能一定要分优先级。我给出的建议是，核心链路优先，加分功能量力而行。

第一优先级是房源管理、用户登录注册、合同与账单管理。这是整个租房系统的骨架，如果这几个模块没做完，项目逻辑上就不成立。

第二优先级是搜索筛选、到期提醒、数据统计。这些功能属于“看起来很专业”的部分，工作量不小，但技术含量适中，做完以后系统完成度会明显上一个档次。

第三优先级是消息通知、收藏功能、在线聊天。这部分我建议直接砍掉或者做成最简单的轮询版，因为涉及 WebSocket 或更复杂的前端交互，不是毕设的核心评分点，花大量时间在上面性价比极低。

我在实际划分时，还加了个“低频但有亮点”的思路：可以用 Redis 做缓存来加速房源列表的访问，虽然毕设并发量根本用不上缓存，但在设计说明里写一句“利用缓存降低数据库压力”就是妥妥的加分项。

2. 技术选型与项目骨架搭建

2.1 版本选型背后的坑

很多人在毕设开头就卡在环境上，核心原因是盲目选择新版本。SpringBoot 3.x 虽然出了很久，但它基于 Spring Framework 6，要求 JDK17 起步，很多配套教程中间件还没完全跟上。我的建议就是老老实实用 SpringBoot 2.7.x + JDK8，这是生态最稳的组合，网上资料一抓一大把，遇到问题随便搜都能找到答案。

配套选型方面：

• ORM 层选 MyBatis-Plus 而不是原生 MyBatis，因为它的条件构造器能省掉大量 XML 里的 if 判断，对赶时间的毕设来说体验是质的提升。
• 数据库连接池用 Druid，监控页面可以直接访问，写论文时还能截图展示“系统具有良好的可观测性”。
• 权限控制用 JWT + 拦截器，无状态认证前后端分离场景下最好用，而且源码量少，答辩时容易解释。
• 接口文档建议引入 Knife4j（基于 Swagger 的增强版），页面比原生 Swagger 好看很多，生成接口文档后写论文的“系统设计”章节直接复制核心部分即可。

这个选型组合看似普通，但胜在每一项都在“够用”和“有深度”之间取得了平衡。避免选择一个过于小众的技术栈导致答辩时老师无从问起，也避免全用最基础的工具导致项目毫无亮点。

2.2 数据库设计要点

数据库设计是整个项目的地基，表结构一旦定下来，后面写代码其实就是照表操作。租房系统核心表建议这么设计：

• user用户表：id、用户名、密码（BCrypt 加密存储）、真实姓名、手机号、角色标识（0 管理员 / 1 房东 / 2 租客）、创建时间。
• house房源表：id、房东 id、标题、小区名、地址、户型（几室几厅）、面积、朝向、楼层、租金、押金方式、出租状态（0 未出租 / 1 已出租）、房屋描述、发布时间。
• tenant租客表：id、用户 id、身份证号、紧急联系人、紧急联系电话、职业信息、备注。
• contract合同表：id、合同编号、房源 id、租客 id、房东 id、起租日期、结束日期、租金、押金、付款周期（月付 / 季付 / 年付）、合同状态、签订时间。
• bill账单表：id、合同 id、账单编号、费用类型（租金 / 押金 / 水电费）、金额、账期（如 2025-01）、缴费状态（0 待缴 / 1 已缴 / 2 逾期）、缴费时间。
• house_apply租赁申请：id、房源 id、租客 id、申请状态（待处理 / 通过 / 拒绝）、申请时间。

字段类型上有几个值得注意的点：金额一律用DECIMAL(10,2)而不是DOUBLE，避免浮点误差；时间字段统一用datetime；面积建议保留一位小数。主键直接bigint自增就好，不需要为了炫技用雪花 ID，那是给自己找麻烦。

外键不要真的在数据库层面建，逻辑外键就够了。一方面数据删除灵活，另一方面避免 MySQL 在外键约束下做级联操作时的性能损耗。答辩时老师如果问为什么不用外键，可以回答“在高并发写入场景下，外键约束会带来额外的锁开销，实际开发中常用应用层保证数据一致性”，这个回答非常加分。

2.3 项目目录结构与分层设计

很多初学者喜欢把所有代码塞到 controller 里，一个方法几百行，看着热闹实则维护成本极高。SpringBoot 项目推荐用标准分层架构：

cn.xx.rent ├── config // 配置类：跨域、拦截器、Knife4j ├── controller // 接口层：接收参数并返回统一结果 ├── service // 业务层：核心逻辑处理 │ └── impl ├── mapper // 数据访问层：MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── dto // 传输对象：接收前端参数 ├── vo // 视图对象：返回给前端的数据 ├── common // 通用类：统一返回结果、异常处理、常量 ├── utils // 工具类：JWT 工具、日期工具 └── RentApplication.java

有一个很关键的习惯要养成：前端传参不要直接绑定entity，而是定义dto；接口返回值不要直接返回entity，而是封装成vo。虽然在小项目里这看起来有点绕，但它的好处很实在：实体类字段有时候包含密码这类敏感数据，直接返回前端就是隐患；而且定义 VO 后，你可以在里面额外添加“房东姓名”“房源图册”这类关联展示字段，前端拿数据会非常舒服。

在common包下定义统一的Result<T>返回类，包含code、message、data三个字段，所有接口统一返回。前端拿到这种结构后，处理逻辑完全一致，不会为每个接口单独写一套解析方法。这块一定要在开工前搭好，否则后面写一个接口写一套返回，光统一格式就能耗掉半天。

3. 核心功能实现与实操要点

3.1 登录鉴权与权限控制实现细节

登录逻辑看似简单，但要做好需要处理几个细节：密码不能明文存储，登录态不能放在HttpSession里由后端维护，因为前后端分离项目需要无状态认证。

我用的方案是 JWT（JSON Web Token）。用户登录成功后，后端生成一个 token 返回给前端，前端存储在localStorage，每次请求在请求头携带Authorization: Bearer token。后端写一个拦截器统一拦截需要认证的路径，解析 token 成功后直接放行，同时在request里设置用户 ID 供后续业务使用。

生成 token 的核心代码如下：

public String generateToken(User user) { Map<String, Object> claims = new HashMap<>(); claims.put("userId", user.getId()); claims.put("role", user.getRole()); return Jwts.builder() .setClaims(claims) .setSubject(user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() + 7L * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

拦截器的关键点在于：白名单路径必须放行，比如/api/user/login、/api/user/register、/api/house/list（因为未登录也要能浏览房源）。不要拦截静态资源。调试时最容易出问题的是遗漏跨域配置，前端请求带 token 时会出现预检请求，后端必须正确响应OPTIONS请求，否则前端会一直报跨域错误。

密码加密直接使用BCryptPasswordEncoder，这玩意儿的好处是每次加密结果都不一样，数据库被脱库也无法反推出原始密码，答辩时提到“采用了不可逆加密算法存储敏感信息”本身就是安全意识的表现。

3.2 房源管理与多条件检索实现

房源管理是整个系统最核心的模块，录入、修改、上下架、列表展示，每个环节都要考虑。我建议把房源列表做成支持多条件筛选的形式：关键词搜索（小区名 / 地址）、租金范围、户型筛选、状态筛选。

用 MyBatis-Plus 的条件构造器写这种动态查询非常舒服，不需要写 XML 里的各种<if>标签：

LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), House::getAddress, keyword) .ge(minRent != null, House::getRent, minRent) .le(maxRent != null, House::getRent, maxRent) .eq(type != null, House::getType, type) .eq(status != null, House::getStatus, status) .orderByDesc(House::getCreateTime);

这里有个容易踩的坑：条件构造器里链条式写法虽然简洁，但要注意like查询的关键词必须提前做空值判断，否则用户什么都没输入时会把整个表的数据全部查出来。别看这个错误低级，实际开发中至少一半的查询副作用都是这种因素导致的。

分页方面，MyBatis-Plus 提供了Page对象，配合分页插件使用：

Page<House> page = new Page<>(pageNum, pageSize); Page<House> result = houseMapper.selectPage(page, wrapper);

前端传pageNum和pageSize，后端返回total（总记录数）和records（当前页数据）。前端用 Element UI 的el-pagination组件可以直接对接。

房源上下架相当于一个状态更新接口，通过updateById修改状态字段即可。有一个小细节要注意：房子处于“已出租”状态时，下架后是否允许编辑？我的做法是已出租房源锁定核心字段（地址、户型、租金），只允许修改描述信息，这是为了模拟真实业务中合同存续期间的约束规则。

3.3 合同管理与到期自动提醒

合同管理是租房系统里最有业务深度的部分，做好了整个项目的档次就上去了。合同的状态流转可以设定为：待生效 → 生效中 → 已到期 → 已退租。

合同创建时，要做几件重要的事：

1. 检查房源当前不是“已出租”状态，避免一房多租。
2. 生成唯一的合同编号，建议格式为HT + 年月日 + 4位随机数。
3. 根据合同起止日期，提前生成所有周期的账单记录。
4. 将房源状态更新为“已出租”，把租客和房源进行绑定。

账单生成的逻辑值得展开一下。如果付款周期是“月付”，合同期限是 12 个月，那就要在签合同的同时生成 12 条账单记录，每条账单对应一个账期。这里写一个循环生成即可，但要注意日期计算方式：第一期的截止日期是起租日期加一个月，第二期以此类推。这种“合同驱动账单”的设计思路在答辩时能展示你对业务闭环的理解。

到期提醒可以用 SpringBoot 自带的@Scheduled定时任务：

@Scheduled(cron = "0 0 8 * * ?") public void remindContractExpire() { // 查询三十天内即将到期的合同 // 给房东和租客发送通知 }

定时任务虽然一行注解就能启用，但有几个隐藏细节需要在测试时关注：时间默认走服务器时区，如果服务器在国外，那每天 8 点执行的含义可能会跟预期不一样，建议在配置文件里明确spring.jackson.time-zone: GMT+8；另外，生产环境如果有多个实例部署，同一时刻定时任务会执行多遍，虽然毕设用不到，但论文明里可以提一句“可以通过分布式锁保证单个实例执行”。

3.4 账单统计与数据可视化

前面把账单生成了，这个模块就是把账单数据进一步加工，让系统管理者能看到经营概况。我建议在后台管理页面放一组统计卡片和一张图表，包括：总房源数、已出租房源数、本月应收租金、本月实收租金、租客总数。

实现方式用 MySQL 聚合函数配合 Java 8 Stream 都可以，但聚合统计这类操作更适合直接让数据库算好返回：

@Select("SELECT IFNULL(SUM(amount), 0) FROM bill WHERE status = 1 AND bill_period = #{month}") BigDecimal sumPaidAmount(String month);

在 MyBatis 中直接写注解 SQL 处理这种简单统计比用 MyBatis-Plus 更直观，因为条件构造器表达不了聚合函数。不过要注意SUM结果可能为null，需要用IFNULL兜底，否则 Java 这边接一个null做运算就直接空指针。

图表展示部分，前端使用 ECharts，后端提供两个统计接口：一个是租金趋势（近六个月的应收实收折线图），一个是房源户型分布（饼图）。前端拿到 JSON 数据后配置一下option就完事。这一块属于典型的面向前端展示型功能，难度不大但视觉效果非常显著，系统演示录屏的时候也是很好的素材。

4. 常见问题排查与避坑实录

4.1 前后端联调的 JSON 格式与跨域问题

前后端分离开发时，第一个拦路虎基本就是跨域。后端 SpringBoot 默认不允许跨域请求，解决方式是写一个配置类：

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

这里有个跟 JWT 相关的隐藏坑：当你携带 token 发起请求时，浏览器会先发一个OPTIONS预检请求，预检请求不会携带自定义请求头。如果拦截器拦截了所有请求并直接校验 token，预检请求就会返回 401，前端表现就是“明明接口能通为什么还是报跨域”。解决方式很简单，在拦截器里先放行OPTIONS请求，再继续校验逻辑。

后端返回的日期类型默认序列化为yyyy-MM-dd HH:mm:ss格式还好，但 LocalDate 类型默认不带时分秒，前端解析时可能报错。建议在配置文件里统一指定：

spring.jackson.date-format=yyyy-MM-dd HH:mm:ss spring.jackson.time-zone=GMT+8

4.2 Maven 依赖冲突与打包问题

SpringBoot 项目最常见的打包报错是Skip Tests没开导致的构建失败，以及主类找不到。排查思路如下：

• 确保maven-compiler-plugin编译版本设置为 JDK8 对应的 1.8，否则你用的 JDK 版本不同会出现编译期方法签名错误。
• 打包时建议执行mvn clean package -DskipTests，跳过测试避免某些测试用例影响构建。
• 依赖冲突集中在druid-spring-boot-starter和knife4j上，有时会因为传递依赖引入旧版 Jackson 导致 JSON 序列化问题。遇到此类情况，可以在pom.xml里排除传递依赖，强制使用 SpringBoot 统一管理的版本。

这里多说一句，很多同学项目开发环境跑得好好的，但打包部署到服务器就起不来，大概率是编译版本问题。配置里的java.version必须和机器上的 JDK 匹配，不然就是各种invalid target release报错。

4.3 定时任务与数据一致性细节

合同到期自动修改状态、账单逾期自动标记，这些操作依赖定时任务，但定时任务里的逻辑一定要考虑幂等性。如果数据重复处理，就会出现租客已经退租了，合同还在“生效中”这种尴尬情况。

我的做法是：在定时任务执行前先查询当前状态，只有状态匹配的数据才更新：

List<Contract> expiringList = contractMapper.selectList( new LambdaQueryWrapper<Contract>() .eq(Contract::getStatus, "生效中") .lt(Contract::getEndDate, LocalDate.now().plusDays(30)) );

同时，数据库层面也加上状态筛选条件，双重保障。这里有个非常值得讲的细节：不要直接在定时任务里调用 service 的更新方法去“批量更新所有到期合同”，而应该一条条查询、一条条更新，这样即使中途失败，只需要观察日志定位到具体哪一条数据出了问题。批量更新的异常日志往往不精确，排错效率很低。

并发部分还有一个隐蔽的问题：用户在前端同时点“确认退租”和定时任务在后台跑“合同到期更新”，可能导致同一条合同被重复更新。解决思路是在更新 SQL 里加状态条件，比如UPDATE contract SET status = '已退租' WHERE id = ? AND status = '生效中'，这样即使两个请求同时到达，也只有其中一个能真正执行成功。

4.4 数据脱敏与接口安全细节

租房系统里面涉及租客身份证号、手机号等敏感信息。哪怕只是毕设，也要有点安全意识。我的建议是：后端接口中，凡是返回身份证号、手机号这类信息，都在 VO 层做脱敏处理，展示时只保留前几位和后几位，比如110***********1234。这不影响功能演示，但论文里写“对个人敏感信息进行脱敏处理”就是一个区别于其他同学的安全意识加分项。

另外，管理员和房东登录后能看到的房源列表边界也要注意：房东进入后台，只能操作自己的房源和合同。所以房源列表查询时，除了条件构造器，还要额外加一个eq(House::getOwnerId, userId)的条件。这块是典型的越权漏洞来源，很多初学毕设的人忽略了“数据范围权限”，结果 A 房东能看到 B 房东的房子，答辩现场被老师点出来会非常狼狈。

5. 项目答辩与说明文档组织技巧

5.1 演示流程的合理设计

毕设答辩时，系统演示一般只有 5 到 10 分钟，很多同学一上来就从前端页面开始点，结果时间全浪费在加载数据和切换菜单上。我的经验是：演示要按“业务故事线”走，不要按菜单顺序走。

可以先演示管理员登录，打开数据统计页面，通过图表快速展示系统整体情况（数据量大、信息全、系统是真实业务场景）。然后切换到一个房东账号，创建一个房源，修改房源信息，模拟租客注册并发起申请，房东确认申请后生成合同。再打开账单页面，展示合同生成的账单列表，演示租客缴费功能。最后演示合同到期提醒和退租操作。你会发现这条线其实就是真实业务的完整闭环，而“按菜单演示”只是在念系统功能清单，没有故事感。

5.2 文档编写的核心素材来源

写说明文档最费时间的是画用例图、ER 图、流程图。手动绘制效率极低，但通常建模工具可以直接从接口和数据表反向生成。有的工具（比如某些 IntelliJ 插件）能直接从数据库反向生成 ER 图，这样出来的图又规范又好看。论文里这些图贴上以后，整个文档的专业度会非常明显。

技术架构选型部分，直接把你最终确定的技术栈按“集成层、接口层、业务层、数据层”写清楚，再把选择每一项技术的理由写一句。不要写“为了毕业设计方便”这种话，要写“SpringBoot 简化了项目初始化和部署复杂度，内嵌容器便于快速启动”“MyBatis-Plus 在满足灵活 SQL 编写能力的同时，大幅提升了开发效率”。这些话就是老师想听的设计理由。

写在后面的一点体会

做完这个租房管理系统，我最大的感受是：毕设选题真的不用贪大。一个 SpringBoot 单体应用、七八张核心表、三到四个角色，只要把业务闭环跑通，把两三个技术细节做出深度，就已经是相当扎实的毕业设计了。我见过很多同学一年前就开始准备，最后却因为反复重构和追求完美导致连基本功能都没做完，这是最可惜的结果。

如果你正在做类似的系统，我的建议是把核心链路先跑通，把登录、房源、合同、账单这几条线先理顺，再去优化细节和界面。等项目能整体运行起来，那种踏实感会帮你把剩下的事情一股气做完。祝你的毕设顺利过关。