基于SpringBoot的城区不动产综合服务平台设计与实现

每年到这个时间点，总能看到一大批计算机专业的同学在选题上纠结，尤其是“城市房产信息网”“不动产综合服务平台”这类题目，几乎是毕业设计里的常青树。但要提醒一句：这类系统看着简单，真做起来，十个里面有八个做成“玩具”——能注册、能登录、能发个静态房源列表就算交差。这显然是不够的。

我今年正好完整地做了一套基于SpringBoot的城区不动产综合服务平台，涵盖了房产交易、租赁管理、经纪人入驻、预约看房、后台审核等完整闭环。这篇文章就把整个项目的选型逻辑、数据库设计、核心接口实现、安全加固和部署调优全部分享出来，特别是那些常规教程里不会讲的坑。想选这个题目的同学，可以直接把这套思路当作蓝本去扩展，比从零开始瞎想要省事得多。

1. 项目整体设计与技术选型思路

1.1 为什么这个题目值得做，以及要避开哪些坑

城市房地产信息网的本质是一个“房源信息中介平台”，它和普通CRUD系统的最大区别在于：业务角色多、状态流转复杂、房源信息字段繁多，并且对安全性的要求高于一般的管理系统。

对比一些常见的选题，比如“图书管理系统”“学生选课系统”，这类题目的业务逻辑单薄，表结构基本两三天就能设计完，答辩时很难展开讲。而房产信息平台天然具备至少五种角色（游客、普通用户、房东/经纪人、管理员）、四种核心业务状态（在售、已售、出租、下架）、三类核心操作流（发布、审核、交易/租赁）。这些业务节点足够支撑你在论文里画出有说服力的流程图和数据流图，也让评委有东西可问、你有东西可答。

但这道题也有明显的坑：很多同学一上来就堆功能，什么地图找房、VR看房、在线签约、电子合同，全都想做。结果就是代码写了一堆，每一个功能都没做完，答辩时连一条完整业务链路都跑不通。我的建议是：核心链路永远优先。所谓核心链路，就是“发布房源 → 后台审核 → 前台展示 → 用户收藏/预约 → 线下成交 → 房源状态变更”。只要这条链路是通的、数据是一致的，这个项目的骨架就站住了。其他功能全是锦上添花。

1.2 技术栈选型背后的理由

我的技术选型如下：

• 后端框架：Spring Boot 2.7.x
• 权限方案：Spring Security + JWT
• 持久层：MyBatis-Plus
• 数据库：MySQL 8.0
• 缓存：Redis
• 前端：Vue 2 + Element UI（后台管理端）、Vue 2 + Vant（用户移动端）

为什么选Spring Boot而不是Spring MVC的传统SSM？原因很直接。Spring Boot的自动配置能把开发环境搭建成本压到最低，起步依赖解决依赖冲突问题，内嵌Tomcat让打包部署一键完成。对于毕业设计这种有时间节点的项目，省下来的环境配置时间应该拿去打磨业务逻辑。

为什么选MyBatis-Plus而不是JPA？我个人的理由是：房产系统的查询场景非常复杂，按区域筛选、按价格区间筛选、按面积筛选、多个条件组合排序，SQL的可控性非常重要。MyBatis-Plus的Wrapper构造器能覆盖90%的单表查询场景，复杂统计再写XML里的自定义SQL，两全其美。JPA虽然开发效率也不错，但一旦查询复杂起来，方法命名会非常冗长，动态条件拼接也没有Wrapper那么直观。

前端选Vue 2没选Vue 3，不是Vue 3不好，而是Element UI和Vant的生态成熟、坑少、教程多。毕业设计的时间本身就紧，与其花一周时间踩Vue 3 + Element Plus的兼容问题，不如用Vue 2把核心功能全部跑通。如果你对Vue 3已经非常熟练，用Vue 3 + Element Plus完全没问题，原理相同。

1.3 模块划分与项目目录结构

系统拆成三个端：前台门户、用户中心、后台管理。前台门户面向游客和普通用户，负责房源展示和检索；用户中心面向登录用户、房东和经纪人，管理个人房源、预约和收藏；后台管理面向平台运营人员，处理房源审核和用户管理。

对应的后端包结构长这样：

com.example.estate ├── common // 通用响应、异常处理、工具类 ├── config // 配置类：Security、Redis、CORS ├── controller // 控制层 ├── service // 业务逻辑层 ├── mapper // MyBatis-Plus持久层接口 ├── entity // 数据库实体 ├── dto // 数据传输对象 ├── vo // 视图对象（用于返回给前端的封装体） ├── utils // JWT工具、分页工具、文件上传工具 └── aspect // 切面（操作日志）

我特别想强调vo包的重要性。很多新手喜欢直接用entity返回给前端，这在毕设阶段可能看不出问题，但一旦遇到“房源实体里有userId，而前端需要的是发布人的昵称”，你就得在entity里加冗余字段，结构就乱了。建议所有接口一律返回vo对象，前端需要什么字段，vo里就有什么字段，后端响应结构保持稳定。

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

2.1 数据库设计的基本盘

房产系统涉及的数据表大致有：用户表、房源表、房源图片表、区域表、收藏表、预约看房表、审核记录表、浏览记录表、公告表。

表不要太多，控制在10到12张左右就足够了。不要为了设计而设计，每一张表都要能说清楚为什么存在。

核心表的设计直接决定业务能否走得通，我逐个说一下。

2.2 用户表与房源表：字段定义的关键细节

用户表的基本字段大家都懂，关键是几个特殊的点：

• role字段用int，0表示普通用户，1表示房东/经纪人，2表示管理员。不要用字符串存角色名，排序和判断都不方便。
• status字段做禁言/封禁标记，被封禁的用户不能登录，也不能操作房源。
• phone字段必须做唯一索引，登录和密码找回都依赖手机号。

下面是简化的建表语句，真实项目中还会加create_time、update_time这类基础字段。

CREATE TABLE `t_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `role` tinyint DEFAULT 0 COMMENT '0普通用户 1房东 2管理员', `status` tinyint DEFAULT 1 COMMENT '1正常 0封禁', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `idx_username` (`username`), UNIQUE KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

房源表是整个系统里字段最多的表，也是最容易设计出问题的表。最高频的坑有三个：

第一，价格字段用DECIMAL而不是FLOAT。FLOAT在MySQL中是非精确类型，做范围查询时会出现边界值判断不准的问题。第二，面积字段建议保留两位小数，和测绘数据的精度对齐。第三，房源编号要单独用一列存一个业务编号，格式比如RJ20250101001，不要直接用自增主键暴露给前端，主键一旦被遍历，平台的房源数据就全被爬走了。

房源表的简化设计如下：

CREATE TABLE `t_house` ( `id` bigint NOT NULL AUTO_INCREMENT, `house_code` varchar(32) NOT NULL COMMENT '业务编号', `title` varchar(100) NOT NULL COMMENT '房源标题', `cover_img` varchar(255) DEFAULT NULL COMMENT '封面图', `price` decimal(12,2) NOT NULL COMMENT '价格（元/月或元/平）', `area` decimal(8,2) DEFAULT NULL COMMENT '面积（平方米）', `house_type` tinyint DEFAULT 0 COMMENT '1整租 2合租 3二手房 4新房', `room_count` tinyint DEFAULT NULL COMMENT '几室', `hall_count` tinyint DEFAULT NULL COMMENT '几厅', `orientation` varchar(10) DEFAULT NULL COMMENT '朝向', `floor` varchar(20) DEFAULT NULL COMMENT '楼层', `decoration` varchar(20) DEFAULT NULL COMMENT '装修情况', `region_id` int DEFAULT NULL COMMENT '所属区域ID', `address` varchar(255) DEFAULT NULL COMMENT '详细地址', `description` text COMMENT '房源描述', `publisher_id` bigint NOT NULL COMMENT '发布者ID', `status` tinyint DEFAULT 0 COMMENT '0待审核 1在售/在租 2已成交 3已下架 4审核驳回', `audit_remark` varchar(255) DEFAULT NULL COMMENT '审核不通过原因', `view_count` int DEFAULT 0 COMMENT '浏览次数', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_region_price` (`region_id`, `price`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源表';

注意idx_region_price这个联合索引，它对应了前台最核心的检索场景“按区域+价格排序”。如果你的查询经常是“某个区域里价格升序”，这个索引就能派上大用场。如果不需要按区域检索，这个索引删掉也行，但实际项目中它几乎必然存在。

2.3 房源图片表与区域表：一套可复用的数据结构

房源图片用一个独立表存多张图片，而不是在房源表里拼一个JSON字符串，这样方便前端做缩略图加载，也方便做图片懒加载。表结构很简单，就是id、house_id、img_url、sort_order四列。

区域表是容易被忽略但很有价值的表。很多同学把“区域”直接做成房源表里的字符串字段，比如“朝阳区”“海淀区”，然后检索用LIKE匹配。这么做的问题非常明显：一旦你要做“区域联动筛选”或“区域房源数量统计”，字符串匹配的效率和扩展性都很差。我建议独立建一张t_region表，字段为id、name、parent_id，如果你愿意做两级联动，用parent_id存父级区域的编号就行。区域表随着后台可维护。

2.4 搭建本地演示数据

光有表结构没有数据，跑起来界面空荡荡的，感觉也差很多。建议写一个data.sql，往房源表里塞20到30条模拟房源，覆盖不同的区域、价格段、房型和状态。这里有个小技巧：用MySQL的递归CTE生成批量数据，省时省力。

INSERT INTO t_house (house_code, title, cover_img, price, area, house_type, room_count, hall_count, orientation, floor, decoration, region_id, address, description, publisher_id, status, create_time) WITH RECURSIVE seq AS ( SELECT 1 AS n UNION ALL SELECT n + 1 FROM seq WHERE n < 30 ) SELECT CONCAT('RJ2025', LPAD(n, 3, '0')), CONCAT('x小区', n, '号房源'), CONCAT('/img/house/', n % 8 + 1, '.jpg'), 2000 + (n * 137) % 8000, 50 + (n * 7) % 80, IF(n % 3 = 0, 1, 2), 1 + n % 3, 1, ELT(1 + n % 4, '东', '南', '西', '北'), CONCAT(n % 25 + 1, '/', 25), ELT(1 + n % 3, '精装', '简装', '毛坯'), 1 + n % 8, CONCAT('幸福路', n, '号'), '这是一套测试房源，适合演示系统功能。', 1 + n % 5, 1, NOW() FROM seq;

生成之后再配合业务手动刷几条已成交和待审核状态的数据，这样三个核心状态在前后台都能看到效果，演示时不会出现“前台一片空白”的尴尬。

3. 核心功能接口的设计与实现

3.1 房源检索接口：条件组合与分页的细节

搜索是房产系统的门面，用户进来第一件事就是找房。搜索接口要支持的关键词包括：区域、价格区间、面积区间、房型、朝向、出租类型。这些条件不是每次全传，接口必须做动态拼接。

用MyBatis-Plus的LambdaQueryWrapper实现如下：

@Override public PageResult<HouseVO> searchHouse(SearchDTO dto) { Page<House> page = new Page<>(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>(); // 状态必须等于在售/在租，未审核和已下架的房源一律不展示 wrapper.eq(House::getStatus, 1); if (StringUtils.hasText(dto.getKeyword())) { wrapper.and(w -> w.like(House::getTitle, dto.getKeyword()) .or().like(House::getAddress, dto.getKeyword())); } if (dto.getRegionId() != null) { wrapper.eq(House::getRegionId, dto.getRegionId()); } if (dto.getMinPrice() != null) { wrapper.ge(House::getPrice, dto.getMinPrice()); } if (dto.getMaxPrice() != null) { wrapper.le(House::getPrice, dto.getMaxPrice()); } if (dto.getHouseType() != null) { wrapper.eq(House::getHouseType, dto.getHouseType()); } // 排序：最新发布优先 wrapper.orderByDesc(House::getCreateTime); Page<House> result = houseMapper.selectPage(page, wrapper); // 组装返回VO List<HouseVO> voList = result.getRecords().stream() .map(house -> convertToVO(house)) .collect(Collectors.toList()); return new PageResult<>(voList, result.getTotal()); }

分页细节容易被忽略，我提两点。

第一，Page对象传入的页码从1开始，前端分页组件通常也从1开始，这个没问题。但如果有人传了超大页码，比如pageNum=9999，MySQL一样会去计算偏移量然后返回空数据，不会报错，但接口响应会慢。建议在入口处对pageNum做一次上限校验，比如最大100页，超出就拉最后一段。

第二，分页查询在数据量大时一定要确认SQL里带了LIMIT ? OFFSET ?，MyBatis-Plus的selectPage默认会做，但如果你在XML里自己手写了select * from t_house，那就不会自动分页了。

3.2 房源详情页：浏览量计数与Redis缓存策略

详情页是高频访问页面，也是最容易被打爆的页面。浏览量的实现，如果每次请求都执行一次UPDATE t_house SET view_count=view_count+1，数据库压力会非常明显。在实际项目中我用了Redis来缓冲浏览量：先更新缓存中的计数，定期批量刷回数据库。

这个方案的实现思路是：用户浏览房源时，先查Redis里的house:view:{id}，有则加1，无则初始化并加1；另外Redis中保存一个标记，当累计到一定次数或者到了定时任务触发时间，再把增量同步到数据库。如果毕设阶段不想引入定时任务，简化方案是：每10次增量写一次库，或者干脆每次访问都加，但给view_count加上索引，压力也不大。毕竟毕设没有高并发，关键在“逻辑自洽”，答辩时被问到如何优化，你能说得清楚，就是加分项。

详情页本身建议加一级缓存，因为房源数据不是高频变化的。我用的方案是Cacheable注解配合Redis，以house:detail:{id}为key，缓存10分钟。等后台审核或房源状态变更时，手动CacheEvict掉对应key。

这里有个容易翻车的点：如果缓存了House实体，而实体里包含description这种大字段，那Redis里存的就是一串很长的JSON。如果房源图片还在实体里做了级联查询，内存和带宽都会被浪费。所以缓存的对象请用轻量级的HouseVO，只保留详情页需要的核心字段。

3.3 发布与审核流程：状态机驱动的业务闭环

用户在发布房源时，系统默认把status设为0（待审核），然后管理员在后台审核。审核通过置为1，驳回置为4并填写audit_remark。

这个流程看起来简单，但容易忽略一个点：用户发布成功之后，能不能再次编辑已发布的房源？答案应该是不能直接编辑，必须重新提交审核，否则就会出现“审核通过的内容被偷偷改成违规内容”的问题。所以update接口也要带状态判断，只允许编辑状态为“待审核”或“审核驳回”的房源。

管理员审核核心代码：

@Transactional public void auditHouse(Long id, Integer status, String remark) { House house = houseMapper.selectById(id); if (house == null) { throw new BizException("房源不存在"); } // 只允许对待审核状态的房源做审核操作 if (house.getStatus() != 0) { throw new BizException("该房源状态不允许审核"); } House update = new House(); update.setId(id); update.setStatus(status); update.setAuditRemark(remark); houseMapper.updateById(update); // 写一条审核日志 AuditLog log = new AuditLog(); log.setHouseId(id); log.setOperatorId(CurrentUser.getId()); log.setAction(status == 1 ? "通过" : "驳回"); log.setRemark(remark); auditLogMapper.insert(log); }

事务一定要加上，不然审核状态更新了而日志没写进去，数据就不一致了。而且注意这个操作只能用于状态为“待审核”的房源，防止重复审核。

3.4 收藏与预约看房：一对多关系与防重处理

收藏表和预约表是多对一关系，一个用户对应多条记录，一个房源对应多条记录。收藏的防重逻辑很简单，唯一索引(user_id, house_id)加上插入时捕获重复键异常即可。

预约看房的防重就要复杂一些。同一套房源，同一个人一天内只能预约一次；同一时段内预约人数要限制，避免看房时间撞车。我用了一张预约表和一组约束来实现：(house_id, user_id, booking_date)做唯一索引，然后业务层校验当天是否已有预约。同时在t_booking表里加一个status字段，0表示待确认，1表示已确认，2表示已取消。

这里有一个在毕设答辩时经常被问到的点：用户在前台发起了预约，这个数据怎么流转到经纪人？我的做法是，后台管理端有一个“预约管理”菜单，经纪人登录后台后能看到属于自己的房源的预约列表，确认后状态变为已确认，前端用户能在“我的预约”中看到进展。这构成了一个完整的双向信息流。

4. 安全方案与权限控制实现

4.1 登录认证：JWT 与 Spring Security 的组合方式

这套系统里，用户、房东、管理员共用一张用户表，登录后根据role字段区分权限。

JWT的流程是：登录成功后签发一个Token，包含userId和role，前端把Token存在localStorage里，每次请求带上Authorization: Bearer <token>。后端用Spring Security的过滤器链，在UsernamePasswordAuthenticationFilter之后加一个JWT过滤器，解析Token并设置SecurityContext。没有Token或Token无效时，对于需要登录的接口直接返回401。

关键点在于哪些接口需要登录。首页的房源列表、房源详情这些是公开的；发布房源、预约看房、收藏是被保护的；后台所有接口都必须是管理员权限。Spring Security的配置可以在configure(HttpSecurity)里做：

http.authorizeRequests() .antMatchers("/api/auth/**", "/api/house/list", "/api/house/detail/**").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated() .and() .csrf().disable();

需要额外说明的是Security的hasRole("ADMIN")会自动给角色加上ROLE_前缀存到GrantedAuthority，所以你在JWT过滤器中构建权限时，要把用户角色拼成ROLE_ADMIN的形式，不然hasRole永远匹配不上。这个坑我踩过，排查了一个小时才发现是大小写和前缀的问题。

4.2 密码加密与敏感数据处理

密码一律用BCrypt加密，不要用MD5，更不要明文存储。Spring Security自带的BCryptPasswordEncoder就够用。注册时加密，登录时matches比对。MD5的问题不仅仅是碰撞风险，更关键的是可以批量查彩虹表，BCrypt自带随机盐，同样的密码每次生成的密文都不一样，安全性不是一个量级。

用户手机号在列表中默认脱敏显示，比如138****8888，只有管理员在后端能看到完整号码。这个在返回VO时直接处理，不要依赖前端脱敏，不然接口被抓包后就泄露了。

4.3 文件上传安全与访问控制

房源图片上传，我用的方案是本地磁盘存储，Nginx映射静态路径访问。有两个细节要注意。

第一个是上传校验。文件后缀白名单限定jpg/png/webp，大小限制在5MB以内，同时校验Content-Type。不要用getOriginalFilename()直接判断后缀，攻击者可以改后缀绕过，比如上传一个shell.jsp.jpg。第二是文件名不能沿用原始文件名，必须用UUID重命名。预留原始文件名的会导致路径穿越漏洞，也可能造成图片覆盖。

图片的访问路径可以直接通过Nginx映射到本地目录，避免走后端接口读图片字节流，既省资源又简单。

5. 前后端联调与性能优化实践

5.1 接口响应体与跨域处理：统一才是硬道理

前后端要约定一个统一的返回结构。我用的结构如下：

{ "code": 200, "message": "success", "data": { } }

后端封装一个Result<T>对象，所有Controller都返回它。这样前端的axios拦截器只看code是不是200，是200就解data，否则统一弹错误提示。一定不要有的接口返回Result，有的接口直接返回List或Map，那前后端联调的时候你会被自己气死。

跨域配置我用CorsFilter解决。本地开发时前端跑在localhost:8080前端端口，后端跑在8081，如果不配置CORS，浏览器直接拦截请求。配置时要指定允许的请求头里有Authorization，否则JWT带不过去。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.addExposedHeader("Authorization"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

5.2 接口慢查询分析与优化手段

系统做完之后，我发现两个接口响应慢：一个是后台房源列表，一个是区域房源统计。排查手段是看MySQL的慢查询日志，或者直接在本地开EXPLAIN。

后台房源列表慢的原因通常是没有把管理员筛选条件和分页逻辑组合好，OR条件导致索引失效。我把查询拆成了两条：先按精确条件过滤，再对结果做模糊搜索，或者在模糊搜索字段上建全文索引。对于毕设规模的数据量，最简单的解决办法是给status和publisher_id建联合索引，让管理员筛选不走全表扫描。

区域房源统计慢，如果用的是GROUP BY region_id，数据量不大的时候完全没问题。但如果你想做得更好，可以在区域表里冗余一个house_count字段，发布、上架、下架时异步更新。这是典型的“空间换时间”思路，答辩时讲出来会显得你有性能意识。

5.3 Docker Compose 一键部署

部署环节，我是推荐Docker Compose的。写一个docker-compose.yml，把MySQL、Redis、后端jar包和前端静态文件一股脑编排起来。这样无论是在本地还是云服务器，都能做到“一键起服务”。

一个精简的编排文件长这样：

version: "3.8" services: mysql: image: mysql:8.0 container_name: estate-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: estate_db ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql restart: always redis: image: redis:6.2 container_name: estate-redis ports: - "6379:6379" restart: always backend: build: ./backend container_name: estate-backend depends_on: - mysql - redis ports: - "8081:8081" environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/estate_db?useUnicode=true&characterEncoding=utf8 SPRING_REDIS_HOST: redis restart: always frontend: build: ./frontend container_name: estate-frontend depends_on: - backend ports: - "8080:80" restart: always

需要注意Docker容器间的通信要用服务名（mysql、redis）而不是localhost，因为两个容器各自的localhost并不互通。后端配置文件里的数据库地址必须是mysql、Redis地址必须是redis。

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

6.1 高频Bug清单：这些坑我几乎每次都踩

下面这些问题，是我自己做这类系统时反复遇到的，整理成速查表，节省你排查时间。

6.2 预约并发“超售”问题与解决方案

如果多个用户同时预约同一套房源，就可能出现一个时间段被重复预约的情况。解决方案是：乐观锁或数据库唯一约束。

最简单有效的方法是在t_booking表上建联合唯一索引，数据库层面直接拒绝重复预约：

ALTER TABLE t_booking ADD UNIQUE KEY uk_house_user_date (house_id, user_id, booking_date);

然后在Service捕获DuplicateKeyException，转换成友好的业务提示“您已预约过这套房源”。这个方法不用分布式锁、不用Redis事务，适合毕设阶段的并发量，同时回答“如何防止重复提交”也是标准答案。

6.3 答辩前要注意的几个细节

最后再说几点答辩经验。第一，系统里一定要有真实的种子数据。有些同学数据库里只有一两套房源，演示的时候点来点去全是同一条记录，观感很差。至少准备20条房源数据，覆盖不同状态。第二，数据库设计的文档要提前画好ER图，答辩时评委几乎必问表关系。第三，自己提前想清楚一个业务场景从头到尾的数据流转，比如用户从注册、登录、发布房源、管理员审核、展示到预约看房的完整路径，讲得流畅就成功了一大半。

我个人的感觉是，这个题目的上限可以做到很高，下限也真的可以做到很低。关键在于你是否愿意在核心业务链路上花心思把它打通、做扎实。把这些基础功能真正做到位，你就已经比大部分选这个题的同学都强了。