企业官网建设流程全解析

如果你最近正在为计算机毕业设计选题头疼，应该已经刷到过大量"基于SpringBoot的XX商城系统"了。商城都快被写烂了，评委一眼扫过去根本分不清谁是谁。相比之下，基于SpringBoot的房源出租信息系统这个方向要聪明得多——它不是简单的增删改查，而是把"租"和"售"两条业务线装进同一个平台，再靠"租赁撮合"这种带点智能味道的逻辑撑起亮点。技术栈正好落在最稳妥的SpringBoot+Vue组合上，无论是实现难度、演示效果还是答辩深度，都处在一个非常适合本科生拿高分的区间。

这篇文章我会从一个完整做完这个项目的人的角度，把从选题、数据库设计、后端接口、前端页面到部署演示、答辩准备的整个链路拆开讲。不整虚的，每一步都是能直接抄作业的干货，同时也把那些网上搜不到的设计理由和踩坑心得一并交代清楚。不管你打算自己从零写，还是已经搭了一半卡住了，这篇文章应该都能帮上忙。

1. 项目定位：为什么"租售一体化"比普通管理系统更容易出彩

1.1 这个系统本质上在做一件什么事

先把业务逻辑说透。房源出租信息系统听名字像是个信息展示网站，但真正做完你会发现，它的核心不是展示，而是撮合。房东手上有多余房源，租客或买家有居住或购房需求，平台要做的就是把双方高效拉通：房东发房源、平台审核、租客检索、系统根据用户偏好推荐、在线下单、模拟支付、生成合同、确认成交。这一整套流程走下来，一个真实的交易闭环就成型了。

"一体化"三个字也不白加。它意味着系统里同时包含租赁和销售两条线路。租赁走租金、押金、租期、续租逻辑，销售走总价、首付、产权状态逻辑。两条线共用一套用户体系、一套房源基础表，但在字段设计和流程处理上各走各的。这种"同一平台、双业务线"的结构，比单一租赁系统或者单一二手房展示系统在复杂度和展示面上高出一个档次。

"智慧"二字则是加分项。它不一定要求你上深度学习算法，而是可以用简单的匹配置信度逻辑实现：系统根据用户的预算区间、期望区域、户型偏好、租期长度，对每一套房源打分排序，把最可能成交的房源推到用户面前。这一点做出来，答辩时就可以名正言顺地说"这个系统实现了基于多维度匹配的房源推荐机制"——评委很吃这一套。

1.2 SpringBoot + Vue：稳妥组合背后的具体版本选择

这个项目我强烈建议用SpringBoot 2.7.x + JDK 8，而不是SpringBoot 3.x + JDK 17。虽然SpringBoot 3已经发布很久了，但对毕业设计来说，不是越新越好。

后端ORM选MyBatis-Plus而不是纯MyBatis，理由很现实：毕设周期内大部分操作是单表CRUD，MyBatis-Plus自带的BaseMapper直接省掉几十个XML文件，分页用PaginationInnerInterceptor几行搞定。也别迷信"手写SQL显得有水平"，在答辩老师眼里，能解释清楚为什么选MyBatis-Plus（减少样板代码、专注业务逻辑）本身就是一种工程意识。

前端选Vue 3 + Vite + Element Plus + Pinia + Vue Router。Vue 2已经停止维护，新项目完全没必要再踩进去。Vite比Webpack更轻更快，启动项目是秒级体验。Element Plus是Element UI的Vue 3版本，表格、表单、弹窗、分页这些后台管理界面组件现成就有，做管理端能省一大半时间。状态管理用Pinia，比Vuex语法更简洁，TypeScript支持也更好。如果你连TypeScript都用不顺，直接写JavaScript也别有压力，毕设阶段能跑通就是胜利。

流程走通之后你会发现，这套选型组合在国内的社区活跃度极高，任何报错基本是"百度一搜就有人踩过同款坑"的状态。最怕的不是报错，是报错搜不到解决方案。选这套组合，等于给自己买了一份最便宜也最全面的"保险"。

2. 功能模块拆解：租、售、撮合三条主线怎么划分

2.1 三种角色与权限边界

系统用户分成三类：管理员、房东、租客/买家。不搞复杂的RBAC权限框架，用一张用户表加一个role字段就够，后端拦截器根据角色判断接口访问权限。

这里有个容易被忽略的设计点：房东也可以作为租客去租房，租客也可以发布房源出售。所以不要把角色和功能做成一刀切的硬绑定，权限判断应该放在"操作"层面而非"用户类型"层面。比如发布房源这个接口，只要是登录用户且通过了实名信息补全，就给开放；审核接口才严格限制管理员角色。这样后端角色校验代码更灵活，也能避免答辩时被问"如果房东也想租别人房子怎么办"。

2.2 出租和出售的字段差异

房源基础信息是共用的：标题、描述、所在省份/城市/区域、详细地址、户型（几室几厅）、面积、朝向、楼层、装修情况、配套设置、图片列表、出租/出售标签。但业务字段必须得拆：

出租房源（rent_house）多出的字段：月租金、押金金额、最短租期、最长租期、出租方式（整租/合租）、起租日期、当前是否已出租。
出售房源（sale_house）多出的字段：总价、首付比例要求、是否满五、产权类型（商品房/公寓/自建房）、是否唯一住房、看房预约时间。

数据库设计时我建议不拆分这两张表，而是在统一的house表上增加一个purpose字段（1=出租，2=出售），再设计一张可选的house_rent_detail和house_sale_detail做一对一扩展。理由很简单：首页列表、搜索、收藏这些最常用的场景都要同时捞两类房源，拆成两张表会让查询逻辑重复且麻烦。一对一的扩展表方式，既保持基础字段的干净，又在特殊业务字段上留了足够空间。

2.3 交易闭环中的状态流转

一体化平台在流程上和普通信息发布网站最大的区别是：它有交易状态。按下单前、下单后、签约后分三个环节：

• 房源状态：待审核 → 已上架 → 租赁中/已预订（卖出）→ 已下架。
• 订单状态（租赁订单/销售订单）：待付款 → 待确认 → 进行中/已完成 → 已取消。
• 合同状态：草稿 → 已签署 → 执行中 → 已到期/已终止。

三个状态是联动的。比如租客对某套房源下单并付款后，房源状态立刻切到"已预订"，其他用户再打开详情页只能看到"已被预订"而不能重复下单；房东确认接单之后，系统自动生成合同草稿，双方在线"确认签署"后合同状态变为已签署。答辩的时候把这条联动链路演示一遍，项目完整度直接拉满，因为你不再是"展示信息"，而是"跑通业务"。

3. 数据库设计：最容易被评审老师追问的一环

3.1 八张核心表的关联关系

数据库设计是答辩时最容易被追着问的部分，因为它直接反映你对业务实体关系的理解。我最终落地的表结构如下：

• user：用户表，存放账号、密码（BCrypt加密存储）、昵称、手机号、角色标识、注册时间。
• house：房源主表，存放基础信息、发布人ID、房源用途（租/售）、价格字段（统一用"分"为单位存整数）、房源状态、审核状态、浏览量。
• house_image：房源图片表，一个房源多条图片记录。
• house_rent_detail：出租扩展字段表。
• house_sale_detail：出售扩展字段表。
• favorite：收藏表，用户ID + 房源ID的联合唯一索引，避免重复收藏。
• order：订单表，通过order_type区分租赁订单/销售订单，关联用户ID、房源ID、订单金额、状态、创建时间、支付时间。
• contract：合同表，关联订单ID、租客ID、房东ID、合同编号、起止日期、租金金额、双方电子签名状态、合同PDF文件路径。

外键我建议不做物理外键，只保留逻辑关联字段。理由有二：一是MyBatis-Plus关联查询本身不依赖数据库外键，物理外键还会拖慢插入、更新性能；二是不少答辩老师自己就反对物理外键，认为在真实企业开发中"外键约束由业务层保证"是更常见的做法。你只要把house.user_id对应user.id、order.house_id对应house.id这套关系在类里面写得清清楚楚，回答时说明"用逻辑外键保证灵活性和性能"，反而能加分。

3.2 金额字段和状态字段的取舍细节

几个容易翻车的细节，提前说清楚：

金额一律用整数"分"存储，不用decimal/double。这是行业共识，原因就是浮点数精度问题。你展示房源列表时把3500000（单位分）除以100转换为元输出页面，答辩提到"为了避免浮点运算误差，金额字段在存储层面统一以分为单位"，这句话本身就是亮点。

状态字段用tinyint，只用0、1、2、3、4这类枚举值，不用字符串描述。一是省空间，二是索引效率高，三是避免"已出租/已被预订/租赁中"这种口语化描述带来的数据不一致。后端用一个HouseStatusEnum、OrderStatusEnum统一映射数字和中文含义，前端拿到状态码后自己转文案。这里注意：枚举值一旦上线不要改数字含义，否则历史数据全乱。设计枚举时把趋势想清楚再定。

house建表的关键语句大致长这样：

CREATE TABLE `house` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '房东用户ID', `title` varchar(100) NOT NULL COMMENT '房源标题', `purpose` tinyint(1) NOT NULL COMMENT '1出租 2出售', `province` varchar(50) DEFAULT NULL, `city` varchar(50) NOT NULL, `district` varchar(50) NOT NULL, `address` varchar(200) NOT NULL, `house_type` varchar(20) DEFAULT NULL COMMENT '户型：3室2厅1厨1卫', `area` decimal(10,2) DEFAULT NULL COMMENT '面积平米', `price` int(11) NOT NULL COMMENT '价格单位分：租金/总价', `deposit` int(11) DEFAULT NULL COMMENT '押金单位分，出租用', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0待审核 1已上架 2已预订 3已下架', `view_count` int(11) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_city_district` (`city`,`district`), KEY `idx_price` (`price`), KEY `idx_purpose_status` (`purpose`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源主表';

注意索引的设计：按城市+区域检索、按价格区间检索、按用途+状态筛选，是房源平台最核心的三种检索路径，对应的联合索引都安排上。另外MySQL 8.0默认字符集乱码问题在utf8mb4下彻底解决，create_time、update_time这类公共字段用DEFAULT CURRENT_TIMESTAMP自动维护，省心。

4. SpringBoot后端：从登录鉴权到租赁撮合的落地路径

4.1 JWT鉴权与拦截器配置

前后端分离项目里，JWT是目前最主流也最容易讲的方案。流程是：登录成功后后端签发token返回给前端，前端每次请求带在Authorization请求头里，后端拦截器校验token并解析出用户身份。

核心配置类有这几个：

// JwtUtil：负责生成和解析token public class JwtUtil { private static final String SECRET_KEY = "your-secret-key-please-change"; public static String generateToken(Long userId, String role) { return Jwts.builder() .setId(userId.toString()) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } }

// 拦截器：解析token，把用户信息放入ThreadLocal public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException("未登录或登录已过期"); } Long userId = JwtUtil.parseToken(token.replace("Bearer ", "")); UserContext.set(userId); return true; } }

这里有一个新手很容易踩的坑：拦截器注册时一定要排除登录、注册、房源列表、房源详情这些匿名可访问的接口。否则你自己调试时会发现，还没登录就列表都打不开了。用WebMvcConfigurer的addInterceptors方法显式添加excludePathPatterns，比注解式拦截器好排查得多。另外token有效期建议设7天，太短会导致用户频繁重新登录，影响演示体验。

4.2 房源发布与多条件检索的关键实现

房源发布的核心接口围绕house主表 +house_rent_detail或house_sale_detail两张扩展表，事务注解@Transactional保证"基础信息+扩展信息"同时写入成功。

检索是房源平台的重头戏。毕设量级的数据量（几百条到几千条房源）完全用不到Elasticsearch，MySQL索引加动态SQL是最合理的解。用MyBatis-Plus的LambdaQueryWrapper拼接条件：

public Page<HouseVO> searchHouse(HouseSearchDTO dto) { LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(House::getStatus, HouseStatusEnum.ON_SHELF.getCode()); if (StrUtil.isNotEmpty(dto.getKeyword())) { wrapper.and(w -> w.like(House::getTitle, dto.getKeyword()) .or().like(House::getAddress, dto.getKeyword())); } if (dto.getPurpose() != null) { wrapper.eq(House::getPurpose, dto.getPurpose()); } if (dto.getCity() != null) { wrapper.eq(House::getCity, dto.getCity()); } if (dto.getPriceMin() != null) { wrapper.ge(House::getPrice, dto.getPriceMin()); } if (dto.getPriceMax() != null) { wrapper.le(House::getPrice, dto.getPriceMax()); } // 默认按发布时间倒序，也可以按价格升序 wrapper.orderByDesc(House::getCreateTime); Page<House> page = houseMapper.selectPage( new Page<>(dto.getPageNum(), dto.getPageSize()), wrapper); return transferToVO(page); }

搜索接口注意几个细节：关键词搜索建议同时匹配标题和地址，命中率更高；城市和区域是下拉选择而不是自由输入，避免脏数据；分页参数pageNum从0还是从1开始前后端要对齐——很多联调问题都出在这个"差一错误"上。

再提一个热词里有人问的"springboot定时任务"：房源平台里天然用得上。我加了一个简单的@Scheduled(cron = "0 0 2 * * ?")定时器，每天凌晨两点把租期已到的房源自动释放为"已上架"状态，顺便清理三个月前已删除的图片记录。这个功能代码量不大，却是一个非常好的"系统思考"加分点，答辩时可以讲"我用了Spring Scheduled做整点状态巡检"。

4.3 租赁撮合的核心：多阈值打分排序

这才是标题里"智慧房源租赁撮合"真正落地的部分。我的实现思路不复杂，但对毕设来说非常够用：写一个MatchService，接收用户携带的需求参数（预算区间、期望区域、户型、租期），和每套房源的属性做逐项匹配打分，总分高者优先展示在"为你推荐"列表中。

public int calculateMatchScore(House house, UserDemand demand) { int score = 0; // 预算匹配：月租金在预算区间内加40分，超出但不超过20%加10分 if (demand.getBudgetMin() != null && demand.getBudgetMax() != null) { if (house.getPrice() >= demand.getBudgetMin() && house.getPrice() <= demand.getBudgetMax()) { score += 40; } else if (house.getPrice() <= demand.getBudgetMax() * 1.2) { score += 10; } } // 区域匹配：完全命中加30分 if (StrUtil.equals(house.getDistrict(), demand.getExpectDistrict())) { score += 30; } // 户型匹配：期望的室数一致加20分 if (parseRoomCount(house.getHouseType()).equals(demand.getExpectRoomCount())) { score += 20; } // 租期匹配：接受最短租期加10分 if (house.getMinRentMonth() != null && demand.getRentMonths() >= house.getMinRentMonth()) { score += 10; } return score; }

这套评分规则按权重排序是：预算 > 区域 > 户型 > 租期。为什么预算权重最大？因为租房决策中价格是首要制约因素，这个逻辑本身说人话就能理解。我在推荐页对得分≥70的房源标记为"高匹配"，60~69标记为"较匹配"，低于60不进入推荐列表只出现在全量列表。推荐结果用Redis缓存10分钟（没有Redis就存本地缓存），避免每次刷首页都全量计算。

如果你想让这块更"高级一点"，可以再加一个简单的用户行为加权：用户收藏过某区域房源，那么该区域的匹配分上浮5分。这个逻辑加进去后，"智慧"二字就不仅仅体现在静态匹配上，还有了一点动态学习的感觉——而实现成本不过是在收藏表上多一条count统计。

5. Vue前端：页面骨架、权限路由与地图找房

5.1 项目目录结构与基础搭建

Vue前端我用Vite初始化：

npm create vite@latest house-front -- --template vue cd house-front npm install npm install element-plus axios pinia vue-router

目录结构是开发前就规划好的，这对后续写页面非常关键：

src/ ├── api/ # 接口请求封装，按业务模块拆分 │ ├── user.js │ ├── house.js │ └── order.js ├── assets/ # 静态资源 ├── components/ # 公共组件（房源卡片、上传组件等） ├── router/ # 路由配置与守卫 ├── stores/ # Pinia状态管理 ├── views/ # 页面组件 │ ├── home/ # 首页、房源列表、房源详情 │ ├── publish/ # 发布房源 │ ├── manage/ # 后台管理 │ └── user/ # 个人中心 └── utils/ # 公共工具（request.js封装等）

Element Plus按需引入还是全量引入？毕设别纠结，全量引入写起来最快，按需引入省体积那是生产环境的优化需求，不是毕设阶段的优先级。在main.js里app.use(ElementPlus)完事。

5.2 Axios封装与动态路由守卫

Axios封装是所有请求的管理中枢。我在utils/request.js里统一做了三件事：设置baseURL = '/api'、请求拦截器携带token、响应拦截器统一处理后端错误码并跳转登录。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') localStorage.removeItem('userInfo') router.push('/login') } ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } ) export default request

路由守卫这部分，关键词里有人提"vue动态路由"，其实毕设很多动态路由需求本质上就是"根据角色显示不同菜单"。用前端静态路由加上meta.roles字段就够了，动态路由是后端返回菜单树，那是大型后台管理系统的玩法，毕设过度设计反而容易被问住。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login' || to.path === '/register') { next() return } if (!token) { next('/login') return } const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}') if (to.meta.roles && !to.meta.roles.includes(userInfo.role)) { ElMessage.warning('没有权限访问该页面') next('/') return } next() })

这套守卫逻辑有一个必须同步落实的点：前端的角色控制只是体验层面的约束，真正权限校验必须写在后端接口上。或者说，前端隐藏菜单只是"不做无谓请求"，后端拦截器校验才是安全底线。答辩时老师如果问"前端路由守卫和后端权限谁更重要"，标准回答是"缺一不可，但安全意义上后端是兜底"。

5.3 首页、详情页与发布页的实现要点

首页是给评委第一印象的页面，必须做到"看起来像个真正的平台"。我分了几个区域：顶部导航（轮播图/搜索框）、分类筛选栏（区域、户型、租金区间）、房源卡片瀑布流、右侧的"为你推荐"列表。地图找房我接入的是高德地图JS API，左侧地图根据当前视野经纬度加载房源标记点，右侧列表同步刷新视野内的房源。这里要注意：地图API的key需要自己在控制台申请，本地开发用"开发版key"会有域名限制，配置securityJsCode后基本没有太大问题。地图标注点建议用高德提供的覆盖物Marker，点击弹出房源小卡片。

房源详情页是撮合逻辑最终的落点。布局：轮播图 + 基本信息 + 右侧价格卡片 + 房东信息 + 底部操作按钮（收藏、在线咨询、立即下单）。详情页里有一个容易被忽略的细节：看清自己是"在售/在租"还是"已预订"，状态不对时下单按钮要置灰禁止点击，否则用户疯狂点击就会触发后面说的并发重复下单问题。

发布房源页要处理的是表单联动的业务逻辑。选中"出租"时展示租金、押金、租期字段，选中"出售"时展示总价、产权信息。这里可以用Vue的v-if配合watch，也可以直接用Element Plus的动态表单校验规则。注意图片上传组件里要限制图片数量（比如最多10张）、大小（2MB以内）和格式，上传前做个前端校验能省掉不少后端判空逻辑。发布成功后按钮状态改为"提交审核中"，引导用户去个人中心看审核进度。

Vue这里还有个容易困惑的点：热词里有人问"vue打包放进springboot中"。原理很简单，前端npm run build之后生成一个dist目录，把里面的内容复制到SpringBoot的src/main/resources/static下，后端直接就能启动访问。不过开发期建议别这么干，前端跑8080、后端跑8081，通过Vite的proxy配置转发/api请求，热更新体验好得多：

// vite.config.js server: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } }

6. 部署、演示与答辩：让评委一眼看到工作量

6.1 从零到跑通的三步操作

项目打包发给别人看的时候，最容易出幺蛾子。我的建议是准备一个"一键启动说明文档"，把环境依赖和启动步骤写得清清楚楚：

1. 安装MySQL 8.0，执行项目根目录下的init.sql，创建一个叫house_rent的数据库，初始数据中包含10个账号、20套房源、3份订单和2份合同。初始化数据是必须做的，空数据库演示效果会大打折扣。
2. 导入SpringBoot项目，修改application.yml中的数据库账号密码，运行HouseApplication主类。后端默认端口8081。
3. 前端项目控制台执行npm install，然后npm run dev，浏览器访问http://localhost:8080，用预设的租客账号（13800000001/123456）登录即可。

这里提一句application.yml配置MySQL连接时，最好加上useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai三个参数，否则中文乱码和时区报错会让你怀疑人生。

6.2 八分钟演示脚本：把链路讲成故事

我建议演示时不要按页面菜单顺序平铺直叙，而是沿着一条业务故事线走：

1. 登录页切入：先讲三种角色，演示租客账号登录。
2. 首页展示：演示搜索筛选、按地域切换地图找房，点开一套高匹配房源。
3. 翻到"为你推荐"：对比推荐列表和普通列表的区别，引出撮合模块的打分逻辑。
4. 收藏 + 在线咨询：展示交互功能，强调"用户行为会影响推荐权重"。
5. 下单 + 模拟支付：跑一遍租赁订单支付流程。
6. 切换房东账号：房东收到新订单，确认接单。
7. 合同生成：系统自动生成电子合同，双方确认签名。
8. 切管理员账号：演示房源审核、用户管理、订单总览、统计分析图表。

这个演示顺序的精髓是"一个业务故事讲到底"，评委跟着故事走，比看你来回切菜单印象深得多。每一步操作之前说一句"接下来我们看XX"，把上下文交代清楚，整个答辩的节奏感就出来了。

6.3 高频答辩问题与参考应答

根据我自己模拟答辩和实际被问到的经验，整理几个高频问题：

"你项目里的'智慧撮合'和普通条件搜索有什么区别？"
答：普通搜索是用户主动输入条件、系统做刚性过滤，比如价格只能选"3000以下还是3000~5000"。我的撮合系统是用户只需要提供一个大致的需求描述（预算范围、偏好的几个区域、想要的户型），系统为每一套房源计算综合匹配分，并允许"价格超预算10%以内但地段极佳"这类房源浮上来，给用户提供的是柔性排序结果而非刚性过滤。

"房源下单时怎么防止两个人同时租同一套房？"
答：数据库层面使用了乐观锁，house表有一个version字段，更新为"已预订"时带上WHERE id = ? AND version = ?，更新失败说明已经被别人抢先。同时在业务层对同一房源的订单创建加分布式锁（或synchronized按房源ID加锁），防止并发创建重复订单。

"你的权限是怎么做的？前端控制还是后端控制？"
答：两层都有。前端通过路由守卫控制页面可见性，改善交互体验；后端通过拦截器校验JWT中的角色信息，对管理员接口进行权限拦截。并且后端以角色判断为准，因为前端可能被绕过，直接构造请求打到接口上。

"系统如果数据量达到百万级，哪些地方会出问题？"
答：目前MySQL的LIKE '%关键词%'检索和单表查询在百万级会出现性能瓶颈。第一，title和address的模糊搜索会退化为全表扫描，需要引入Elasticsearch做全文检索；第二，推荐列表的实时计算会变慢，需要把匹配结果预计算并缓存，或者引入离线计算任务；第三，图片访问需要用独立的对象存储和CDN分流。这些都属于可以谈的优化思路，"知道瓶颈在哪"比"已经做了优化"在某些老师眼里更值钱。

7. 开发过程中踩过的坑与后续优化方向

7.1 三个必踩的坑

Long类型主键传给前端精度丢失。后端主键用bigint，如果使用雪花算法或者自增超过JavaScript的Number.MAX_SAFE_INTEGER（9007199254740991），前端拿到的ID末尾会变成...0000，导致详情页打开失败。解决方案很简单：在Jackson配置里把Long类型统一转为字符串输出，或者用@JsonSerialize(using = ToStringSerializer.class)标注主键字段。这个问题有多隐蔽？你本地测试数据ID都是个位数，永远不会发现，等导入大量初始化数据后才会炸。提前处理，别赌。

前后端时间字段格式对不上。后端LocalDateTime默认序列化出来是一串数字（时间戳），前端Element Plus的日期组件却习惯接收yyyy-MM-dd HH:mm:ss字符串。在application.yml里配置：

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

同时数据库连接串里加serverTimezone=Asia/Shanghai，三处时区对齐后基本不会再出问题。

并发下单的脏数据。用户快速点击"立即下单"按钮，前端没有做防抖，后端也没有做并发控制的话，同一个人可能创建出好几条相同内容的订单，严重破坏演示效果。我在后端下单接口上用synchronized (String.valueOf(houseId).intern())锁住房源ID，同时在order表加(user_id, house_id)的前缀条件来保证同用户同房源未完成的订单只有一条。前端的提交按钮也做了loading状态防重复点击。两层防护，稳妥。

7.2 这几点优化可以做但不着急

项目主体完成、答辩PPT做完之后，如果还有富余时间，性价比最高的几个扩展方向：把MySQL的LIKE搜索升级为全文索引方案；用WebSocket给房东推送"新订单提醒"；管理端增加ECharts成交趋势、房源价格分布等可视化报表页面；引入Redis缓存房源详情页的访问热点数据。这几个方向每个都有明确的应用场景和实现方案，写在论文"系统展望与不足"一节里，比干巴巴写"进一步提高系统性能"要有说服力得多。

另外，部署到云服务器时有一个非常好的可选项——用宝塔面板的Docker功能部署SpringBoot和MySQL。热词里有人搜"宝塔docker部署springboot"，确实是个省心方案：后端打成jar包，写个Dockerfile，映射宿主机端口，MySQL也用容器起一个，前端打包后的静态文件放在Nginx容器里并配置代理转发到后端接口。整个过程一小时左右能跑通，弄完之后你从任何一台电脑访问服务器IP都能看到项目在运行，答辩时随手打开手机展示的效果远强于"只能在我的电脑上跑"。

最后说点我个人的感受。做这类毕设项目，最值钱的收获往往不在最终代码量，而在于你亲手把一条"房东发布 -> 平台审核 -> 租客搜索 -> 系统推荐 -> 在线下单 -> 合同签署"的完整业务链跑通了一遍。你会第一次真正感觉到框架不是背概念背出来的，而是用来解决一个个具体问题的：JWT是为了让API认得你是谁，状态机是为了不让房源被重复下单，匹配分是为了让用户少翻几页就能看到合适的房子。带着这种"每个设计都有它存在的理由"的状态走进答辩教室，你说的每一句话都会比背稿子自信得多。