1. 项目概述与行业背景
房屋租赁市场近年来呈现爆发式增长，特别是在一二线城市，年轻群体的租房需求与日俱增。传统的线下中介模式存在信息不对称、交易效率低下、服务费用高昂等问题。基于SpringBoot+Vue的智慧住房租赁平台正是为解决这些痛点而生，它通过技术手段连接房东与租客，实现高效、透明、安全的在线房屋租赁全流程服务。
这个系统我前后迭代过三个版本，从最初简单的信息展示到现在的全流程智能化服务，踩过不少坑也积累了很多实战经验。相比市面上很多学生作品，我们这个系统更注重实际业务场景的还原，比如引入了电子合同签署、在线押金托管、智能推荐算法等商业化功能模块。
2. 核心技术选型解析
2.1 后端技术栈：SpringBoot的深度应用
选择SpringBoot作为后端框架主要基于以下几个考量：
- 快速开发：通过starter依赖和自动配置，可以快速搭建起包含安全认证、数据库访问、缓存等基础功能的项目骨架。比如我们使用spring-boot-starter-security实现RBAC权限控制，用spring-boot-starter-data-jpa操作数据库。
- 微服务友好：虽然当前是单体架构，但SpringCloud的兼容性为后续服务拆分预留了空间。我们特别注重了模块化设计，将用户服务、房源服务、订单服务等按领域划分package。
- 生态丰富：整合了Elasticsearch实现房源搜索、Quartz处理定时任务（如合同到期提醒）、Redis缓存热点数据等。
实际开发中发现SpringBoot默认的Tomcat容器在高并发场景下表现不佳，后来我们通过调整线程池参数（server.tomcat.max-threads=200）和启用HTTP/2解决了性能瓶颈。
2.2 前端技术栈：Vue3的组合式API实践
前端采用Vue3+Element Plus的组合，主要优势在于：
- 组合式API让代码组织更灵活，特别是对于复杂的房源详情页，我们将地图组件、图片轮播、预约看房等功能拆分为独立composable。
- TypeScript支持完善，接口定义与后端DTO严格对应，减少了前后端联调时的类型错误。
- 按需加载的组件库减小了打包体积，首屏加载时间控制在1.5秒内。
这里分享一个性能优化技巧：对于房源图片这种静态资源，我们没有直接放在项目中，而是通过Webpack的externals配置引用了CDN地址，打包体积减少了40%。
2.3 数据库设计：MySQL的优化实践
数据库设计有几个关键点值得注意：
- 采用分表策略：基础信息表（如用户表）与业务表（如房源表）分开，高频访问的表（如收藏表）单独优化。
- 空间数据存储：使用MySQL的GIS扩展存储房源坐标，配合R树索引实现3km范围内的房源筛选，查询性能比普通经纬度计算提升5倍以上。
- 字段设计避坑：早期版本将房源图片直接以JSON数组存在一个字段里，后来发现无法建立有效索引，调整为单独的图片表后，列表页加载速度提升明显。
3. 核心功能模块实现
3.1 智能房源匹配系统
这个功能模块的技术实现比较复杂：
- 用户画像构建：基于用户的浏览记录、收藏行为、已租房屋特征等数据，使用TF-IDF算法提取关键词权重。
- 房源特征提取：从房源描述中抽取户型、朝向、装修等结构化特征，结合地理位置、价格等数值特征。
- 匹配算法：采用改进的余弦相似度计算用户偏好与房源特征的匹配度，前10%的房源会进入推荐池。
实际运行中发现冷启动问题严重，新用户没有足够行为数据。我们的解决方案是：
- 注册时让用户选择3个最关注的房源特征（如"近地铁"、"带阳台"）
- 结合用户基本信息（如职业、年龄）匹配相似用户的历史偏好
- 使用热度降权策略避免热门房源过度曝光
3.2 在线签约与支付系统
这是确保交易安全的核心模块，我们实现了：
- 合同模板管理：使用Freemarker动态生成合同，关键字段（如租金、租期）自动填充。
- 电子签名：集成e签宝的SDK，通过短信验证码+手写签名双重认证。
- 资金托管：与支付宝的担保交易接口对接，租金分期释放给房东。
踩过的一个坑：初期直接调用支付接口没有做幂等性处理，导致偶发的重复支付。后来增加了本地交易流水表+唯一索引的方案彻底解决了这个问题。
3.3 房东端房源管理系统
为房东提供了完善的管理功能：
- 智能定价建议：基于周边同类房源的历史成交数据，使用时间序列预测模型给出价格区间。
- 看房预约管理：集成腾讯日历SDK，自动避免时间冲突，支持扫码核销。
- 数据看板：使用ECharts展示房源浏览量、收藏量、咨询量的趋势变化。
一个实用技巧：房源上下架操作我们采用了状态机模式，定义了明确的状态转换规则（如"已租出"的房源不能直接修改为"可租"），避免了业务状态混乱。
4. 部署与性能优化实战
4.1 云原生部署方案
我们最终采用的部署架构：
- 前端：打包后的静态文件托管在腾讯云COS，通过CDN加速
- 后端：使用Docker打包为镜像，K8s集群部署3个Pod
- 数据库：阿里云RDS MySQL 8.0，配置了读写分离
- 中间件：Redis集群缓存热点数据，RabbitMQ处理异步任务
特别要强调的是健康检查配置：SpringBoot Actuator的/health端点配合K8s的livenessProbe，可以在服务异常时自动重启容器，大大提高了系统可用性。
4.2 高并发场景应对策略
在毕业答辩前的压力测试中，我们发现了几个性能瓶颈：
- 房源搜索接口：当同时在线用户超过500时，响应时间从200ms飙升到2s
- 解决方案：给Elasticsearch增加了3个数据节点，查询改用scroll分页
- 首页推荐计算：CPU密集型操作导致节点负载过高
- 改为定时任务预计算，结果缓存到Redis
- 图片上传：大量小文件导致磁盘IO瓶颈
- 接入对象存储服务，前端直传OSS
4.3 安全防护措施
在安全方面我们做了多重防护：
- 接口防刷：使用Guava的RateLimiter实现方法级限流
- SQL注入：不仅用了PreparedStatement，还对所有DTO字段做了正则校验
- XSS防护：前端用DOMPurify过滤，后端再统一转义
- 敏感数据：手机号等字段数据库存储时做了AES加密
5. 典型问题排查实录
5.1 地理位置查询异常
现象：附近房源查询有时返回空结果，但数据库确有数据
排查过程：
- 检查SQL日志发现坐标参数偶尔为null
- 追溯前端发现iOS设备获取定位需要https
- 进一步排查是某些浏览器会阻止非安全上下文的定位请求
解决方案：
- 强制全站HTTPS
- 增加定位失败时的降级处理（按城市默认中心点查询）
5.2 缓存雪崩问题
现象：每天凌晨系统响应变慢
原因分析：
- 很多缓存设置了24小时过期时间
- 凌晨批量任务重启导致缓存集中失效
最终方案： - 基础数据缓存改为永久有效，通过消息队列通知更新
- 业务数据缓存过期时间增加随机偏移量（±2小时）
5.3 事务不一致问题
现象：偶尔出现房源已出租但订单未生成的情况
根本原因：
- 涉及房源状态更新、订单创建、消息通知等多个操作
- 原实现方法间用@Transactional注解，但异常处理不完善
重构方案： - 引入Spring Retry实现重试机制
- 新增补偿任务定时检查不一致状态
- 关键操作增加操作日志便于追溯
这个项目从技术选型到最终上线历时6个月，最大的体会是：业务复杂度往往比技术难度更具挑战性。比如电子合同的法律效力问题，我们咨询了专业律师才确定合规方案；再比如租金支付的各种异常场景（部分退款、提前解约等），测试用例写了200多个才覆盖完整。建议后来者在做类似系统时，一定要先深入理解行业规则，再考虑技术实现。