企业官网建设流程全解析

没接触过这类题目的人可能以为“房产中介管理系统”就是很传统的CRUD，一张房源表、一张客源表、一张成交表，套个SpringBoot就完了。实际动手之后你会发现，真正让你头疼的不是业务本身，而是版本兼容、权限设计、前端打包、部署环境这一整条链路上的细节问题。这篇内容我打算围绕SpringBoot做一个基于JAVA Web的房产中介管理系统，把我自己从项目骨架搭建到部署上线的完整思路和踩坑过程写出来。不管是做课程设计、毕业设计，还是想把这套系统商业化落地，看完你至少能少走半个月弯路。

1. 版本组合先想清楚，别让SpringBoot版本毁了你半个月

1.1 JDK与SpringBoot的绑定关系

很多人一上来就新建SpringBoot项目，IDEA默认给你生成3.x版本，然后拿着一堆2.x时代的教程去配，结果启动就报错，卡在依赖下载和自动配置上。这其实是SpringBoot版本差异造成的。SpringBoot 2.7对应的是JDK 8，SpringBoot 3.x强制要求JDK 17及以上。如果你机器上装的是JDK 8，那就老老实实用2.7版本，不要强行上3.x。

我这里说的不是老古董思想，而是实际项目中最稳的组合。房产中介管理系统这种业务型系统，用不到SpringBoot 3.x带来的虚拟线程、GraalVM这些新特性，反而因为生态版本差异，很多第三方组件跟不上。记得我一开始也试过用3.x，结果MyBatis-Plus还没完全适配，需要额外加适配包，集成复杂一点就莫名其妙的ClassNotFound。直接退回2.7.18，一次性跑通，省心很多。

还有一个关键点，SpringBoot 2.7之后，自动装配机制从spring.factories迁移到了AutoConfiguration.imports，如果你翻到老教程里让你手动在META-INF/spring.factories里加配置类，那个写法在新版本里已经不生效了。所以版本定了，教程也得用配套的，这是最容易踩的坑。

1.2 前后端形态：模板引擎还是前后端分离

房产中介系统有一个特点：页面数量不多，但表单逻辑比较重，比如房源录入、客源跟进、成交合同。做这类项目，前端选型一般有两种路线。

第一种是服务端渲染，用Thymeleaf或FreeMarker，后端直接把数据塞进模板，前端页面由后端控制跳转，这种方式开发速度快，适合单人开发和答辩展示。第二种是前后端分离，前端用Vue或React，后端只提供JSON接口，前端通过axios调用。两种我都做过，我的结论是：如果这是课程设计或毕业设计，想省时间，直接用Thymeleaf就够；如果你想在项目里展示点现代Web开发能力，那就用Vue3加Element-Plus搞分离式开发。

前后端分离有个隐藏成本：部署的时候要处理跨域，要处理前端打包后的静态资源路径，还要考虑接口鉴权时的Token存储。这些不是不能解决，但每一个都会占用你排期之外的时间。所以选型之前先问你自己，这个项目的时间预算到底有多少。

我做房产中介管理系统时选的是前后端分离，理由很简单，方便远程演示和部署到云服务器。前端Vue打包成静态文件之后直接扔进SpringBoot的src/main/resources/static目录，最终打成一个jar包，这样部署时不用同时跑两个服务，直接java -jar就行，服务器上少操心一个进程。

2. 从零搭建房产中介系统的工程骨架

2.1 包结构：推倒重来比重新拼装更简单

新人写项目往往喜欢在一个包下堆所有类，Controller、Service、Mapper全放一起，几千行代码堆下来，自己都分不清谁是谁。房产中介系统虽然业务不算复杂，但涉及到的模块不少：房源管理、客源管理、预约看房、合同、员工、权限、统计报表。如果包结构一开始不分好，后面每加一个功能都是在熵增。

我习惯的分包方式是按模块划分而不是按技术层次划分：

• controller：按模块拆分，HouseController、CustomerController、AppointmentController
• service：抽象接口加实现类，方便扩展和维护
• mapper：MyBatis-Plus的Mapper接口，数据处理层
• entity：数据库表对应的实体类
• dto：前端交互用的数据对象，不要直接把Entity暴露给前端
• config：配置类，包括MyBatis-Plus、WebMvc、Cors、拦截器等
• common：统一返回结果、全局异常处理、常量定义和工具类

这个结构看起来没什么花哨，但足够干净。尤其要注意dto和entity的分离。很多新手图省事直接把Entity返回给前端，结果前端多拿了你不想暴露的字段，比如员工密码hash值，这不光是风格问题，是安全问题。用DTO做隔离，一劳永逸。

2.2 一百行代码跑通MyBatis-Plus逆向生成

房产中介系统的表结构不算少，字段也偏多，比如房源表要有面积、朝向、楼层、装修情况、价格、周边配套等等。手写实体类和Mapper太费时间了，直接用MyBatis-Plus的代码生成器，能省一半时间。

MyBatis-Plus提供了一个AutoGenerator，配合Freemarker模板引擎，可以根据数据库表自动生成Entity、Mapper、Service、Controller。配置的时候只需要注意几个点。

第一，数据源URL要写对，useUnicode=true&characterEncoding=utf8必须带上，否则中文乱码够你折腾一天。第二，生成策略里要设置IdType.ASSIGN_ID，这样主键自动生成雪花ID，不依赖数据库自增。第三，Controller层建议生成完之后改造一下，因为默认生成的Controller是直接操作实体类的，不符合我们前面说的DTO隔离思路。

生成完代码之后，项目的基础框架就有了一套。接下来的业务开发基本可以告别重复劳动，专注写核心逻辑。这套流程跑通一次之后，你对MyBatis-Plus的自动装配原理也会顺手了解不少。

2.3 统一返回结果与全局异常

房产中介管理系统前后端分离之后，接口返回的数据结构必须统一。我最常用的是一个Result类，包含code、message、data三个字段。成功时code为200，失败时code为具体业务错误码，比如预约时间冲突发401，房源不存在发404，登录失效发403。

全局异常处理用@RestControllerAdvice，配合@ExceptionHandler把各类异常统一封装成Result返回。否则默认情况下，接口一通就返回SpringBoot的Whitelabel Error Page，或者500状态码加一堆堆栈信息，前端根本没办法判断错误原因。

这里有个细节，业务异常要自定义。比如预约看房时判断时间段是否冲突，冲突了要抛一个自定义的BizException，然后在全局异常处理器里捕获，返回给前端一个合理的提示。如果你不这样做，所有异常都靠try-catch一层层往上抛，代码里到处都是异常处理的痕迹，后面维护起来就是灾难。

3. 房源、客源、成交：中介业务的三个核心状态流

3.1 房源检索：状态位加时间戳，别只靠一张表做所有事

房产中介系统里最核心的数据就是房源。基本字段无非是小区名、户型、面积、楼层、朝向、装修、价格、图片、状态。房源状态一般有这么几种：待售、预约中、已成交、已下架。很多人的第一版设计就是加一个status字段，查询的时候带条件过滤，看起来没什么问题，但实际操作下来会碰到两个痛点。

第一个痛点是房源图片。一张房源可能有5-10张图片，如果直接存在房源表里，用逗号拼接URL，查询出来还要前端自己切分，而且后面想加图片主图标识、排序、图片分组等信息都很别扭。我当时的做法是单独建了一张house_image表，外键关联房源ID，每张图一个记录，用sort_order控制排序。这样后续扩展非常方便。

第二个痛点是价格变动。一套房在中介挂牌的时间可能很长，中间可能降价、涨价好几次。如果只在房源表里记录一个当前价格，那以后想查“这个房源价格变化了多少次，什么时间调的价”就要靠日志去猜。我的建议是加一张house_price_log表，每次价格变动写入一条记录，房源表里只维护当前价格。这样临门一脚还能给客户展示“这套房源一个月内降价两次”，是有说服力的销售工具。

3.2 预约看房到成交跟进的状态机

房产中介的业务本质上是一个状态流转：房主挂牌，中介录入房源，客户浏览房源，客户预约看房，经纪人带看，客户意向确认，签约成交，交房过户。每一步都有对应的数据记录和时间节点。

订单状态如果只靠status字段硬存，你会发现业务一复杂就撑不住：谁在什么时间改的状态？改状态之前是什么？对应的操作人是谁？这些信息全是黑的。所以我在设计预约和跟进流程时，用了两张表：一张appointment记录预约主信息，包含房源ID、客户ID、经纪人ID、预约时间、状态；一张appointment_status_log记录状态变更历史。预约状态大概是：待确认、已确认、已完成、已取消、已爽约。

为什么非要这个状态机？因为做中介系统绕不开一个行业特色：纠纷处理和业绩核算。客户约好了没去看，算不算经纪人空跑？成交之后突然毁约，佣金怎么退？这些都需要历史轨迹来撑腰。你提前把这些状态转换记录好，后面不管是做统计报表还是处理客诉，都有据可查。

3.3 短信通知这类“加分项”怎么做才不翻车

预约看房时间快到了，给客户和房主发一条短信提醒。这种功能看起来是加分项，但实际操作时最容易翻车。很多人一上来就接第三方短信平台，比如阿里云短信、容联云，测试阶段几十条短信发出去，钱不多，但环境变量、签名审核、模板ID这些流程走下来，可能卡你一整天。

如果只是做毕业设计或者课程展示，我建议先把短信通知做成一个接口，后台配置好开关，开发环境用日志打印来代替真实发送。上线前再打开真实短信通道，这样开发期不会被第三方接口限流，也不会因为签名审核没过浪费时间。真正接入平台的时候，配置方式也很标准：在application.yml里配置accessKeyId、accessKeySecret、signName、templateCode，用一个注入短信服务商SDK的Service去调用。

这里提醒一句，很多短信平台要求你账户里有余额，签名也需要审核，这些都要提前准备，别等到演示前一天才发现短信根本发不出去。

4. 权限设计：建议用Sa-Token替代Spring Security

4.1 Spring Security对新手的三大坑

房产中介管理系统天然需要权限控制：普通中介人员只能看自己名下的客源和房源，店长可以查看全店数据，管理员可以管理员工账号和系统配置。这种角色权限需求非常典型，几乎每个做这类题目的人都会第一时间想到Spring Security。

但我要直说，Spring Security确实强大，但对新手来说坑太深。第一个坑是配置繁琐，SecurityConfig里一堆HttpSecurity、AuthenticationManager、UserDetailsService配置，还有密码加密方式要显式指定，版本不同API还不一样。第二个坑是跨域与CSRF的配合，如果你想做前后端分离，不关CSRF会导致POST请求全部403，关了又需要额外配置跨域放行，很多人卡在这里根本不知道是哪个环节出的问题。第三个坑是会话与Token的获取，Security默认用Session管理登录态，你要改成Token模式又得引入JWT，然后过滤器链里还要插入自定义Filter，里面的执行顺序稍微一调错就各种奇怪问题。

不是说Spring Security不能用，而是这个项目只需要简单的RBAC角色权限控制，没必要引入那么重的框架。我后来在项目里换成了Sa-Token，整个配置量只是Spring Security的五分之一，登录、踢人下线、权限校验、token续期这些常用功能都有现成API。

4.2 Sa-Token落地登录鉴权

Sa-Token的使用方式非常简单。先引入依赖，然后在配置类里启动Sa-Token拦截器。登录时调用StpUtil.login(userId)生成Token，前端每次请求在Header里带上satoken字段，后端通过StpUtil.getLoginId()获取当前登录人ID，接口上通过@SaCheckPermission("house:add")注解做权限校验。

权限的数据结构我也简化成了经典RBAC：一张sys_user表、一张sys_role表、一张sys_menu表，再加上用户角色关联表和角色菜单关联表。登录的时候一次性把用户角色和权限标识加载进来，用Sa-Token的StpUtil.setSession缓存起来。这样每次接口校验权限时，直接查缓存，性能上完全没问题。

这套东西最明显的优势是全套中文文档，遇到问题查起来顺利得多。你要是用Spring Security，报错信息都是英文写的一堆链式调用，排查成本高得多。

4.3 行级权限与数据隔离

权限控制在房产中介系统里除了“能不能进这个菜单”之外，还有一个更隐蔽的需求：数据隔离。也就是说，普通经纪人登录之后，只能看到自己名下的房源和客源，不能看到同事的。这个问题光靠角色权限是解决不了的，因为角色权限管的是“能不能看房源”这个动作，而数据隔离管的是“能看谁的数据”。

我的做法是在数据模型里增加owner_id字段，记录数据的归属人。所有房源和客源列表查询，在SQL层面强制拼接owner_id = 当前登录人ID的条件，而不是靠前端传参控制。这样即使前端被恶意篡改，也拿不到别人的数据。店长角色另加一个“全部数据”的查看开关，用数据权限类型字段控制，比如data_scope = 1表示本人，data_scope = 2表示全部。

这种行级权限的实现思路不复杂，但对系统安全性提升很明显，在答辩的时候也是一个不错的亮点，比单纯说“我用了Spring Security”更有说服力。

5. 前端并入SpringBoot的两种打包姿势

5.1 Vue打包放static：放不对就404

我前面说我选的是前后端分离，最终部署是打包成单jar。这里有一个很容易踩坑的点：Vue打包之后的dist目录里的index.html、static文件夹该放哪。

很多人直接整个dist里的文件都扔到src/main/resources/static下，结果每次刷新页面或者直接访问某个子路由时就404。根本原因是Vue的路由用了history模式，浏览器刷新会带着/house/detail/1这样的完整路径去请求后端，而后端根本没有对应的Controller来响应这个路径，于是就返回404。

解决办法有两个：第一个是在application.yml里配置Spring Boot的spring.mvc.throw-exception-if-no-handler-found=true，再加一个ViewController把未匹配到的路径重定向到index.html；第二个，也是最省心的办法，把Vue路由的createWebHistory换成createWebHashHistory，URL里多一个#号，样子上不如history模式美观，但刷新和直接访问子路由都不会出问题。

因为我这个系统主要是内部人员使用，对URL美观度要求不高，所以我用了hash模式。你要是想拿histroy模式出去展示美观性，那就得配好路径重定向逻辑，两者选一个就行。

5.2 单jar部署与服务器环境差异

前端静态资源整合进SpringBoot之后，整个系统打成一个可执行jar包。部署之前有几个检查必须做：第一个，application.yml里的数据库连接写的是你本地的localhost:3306，发布到服务器上要改成服务器的内网地址或公网地址，不能漏。第二个，文件上传路径要单独配置，上传的图片和附件不要落在jar包内部，否则每次重新部署上传的数据就全没了，正确姿势是配置一个服务器上的绝对路径，比如D:/upload或者/data/upload。

独立出来的上传目录还有一个好处，就是接下来你如果做Nginx反向代理，可以直接用alias或root把上传目录暴露成静态资源路径，前端就可以直接通过URL访问图片。哪怕你没有Nginx，SpringBoot里配置一个WebMvcConfigurer来映射/upload/**路径到磁盘目录也是可以的。

5.3 多环境配置与端口注意事项

房产中介系统既然要部署到不同环境，那配置管理就不能只靠改一个application.yml。我把连接参数按环境拆成了application-dev.yml和application-prod.yml，而主配置文件里只留下spring.profiles.active: @activeProfile@这种占位符形式，由Maven打包时通过-P参数动态指定环境。

比如我打生产环境包的时候会用mvn clean package -Pprod，打开发环境包用-Pdev，这样代码仓库里的配置不会因为本地和服务器环境不同而频繁改动。端口上我用的是server.port=8080，注意云服务器如果是默认安全组策略，只开放80、443端口和常用端口，8080入方向规则要在云控制台手动开放，很多人配置了半天部署好了，外面访问不了，就是因为安全组没放行8080端口。

6. 整合WebSocket与消息队列的两个加分玩法

6.1 WebSocket做看房预约实时提醒

房产中介系统里有一个场景非常适合用WebSocket：客户在系统上提交看房预约之后，后台经纪人的电脑或者手机端能立刻收到一条提醒。如果用传统HTTP定时轮询，每两三秒刷一次接口，浪费资源不说，实时性也差。用WebSocket就能把数据主动推到浏览器端，体验上会明显好一截。

SpringBoot集成WebSocket不复杂。引入spring-boot-starter-websocket依赖，配置一个WebSocketConfigurer注册WebSocket处理器。我在项目里用TextWebSocketHandler实现了一套简单的消息推送，预约创建成功之后，服务端调用WebSocketSession发消息，前端通过onmessage事件接收并弹提示。要注意的是，WebSocket的握手阶段需要和登录状态联动，我在Interceptor里读取了Header中的Token并校验，未登录的握手请求直接拒绝。

心跳保活也是一定要处理的，不然客户端和服务端之间的TCP连接会因为超时被网关或者防火墙断开。我每30秒发送一个ping消息，客户端回一个pong，这套心跳机制跑下来连接很稳定。

6.2 ActiveMQ处理异步消息

还有一个加分项是消息队列。房产中介系统里哪些操作需要异步？比如客户签约后，要同步通知财务、中介经理、房源维护人，并生成一条合同日志。如果全都在签约接口里同步处理，接口响应时间会变慢，而且一旦某个通知服务有问题，整个签约流程都报错。改用ActiveMQ或者RabbitMQ之后，签约接口只管生成合同，然后往队列里发一条消息，后面的事情由异步消费者去处理。

SpringBoot整合ActiveMQ比传统JavaEE时代简单一个量级，支持JMS规范，只要配置好ConnectionFactory和Queue，生产者用JmsTemplate.convertAndSend，消费者用@JmsListener注解监听队列就行。这里提醒一件事：消息队列的事务边界要理清楚。如果监听器里操作数据库，要和普通方法一样用@Transactional，但要注意消息确认机制，建议先写入消息再执行业务操作，否则会出现消息丢了但业务还继续跑的问题。

7. 部署和演示阶段常见问题速查

7.1 跨域配置不生效的核心原因

前后端分离开发时，前端跑在localhost:8081，后端跑在localhost:8080，接口一调用就遇到跨域问题。很多人写了一个CorsFilter，却发现有时候生效有时候不生效，甚至前端都报了CORS错误，但后台日志里根本没有请求进来。这是因为SpringBoot处理跨域的机制里，CorsFilter的执行顺序要在Spring Security的过滤器链之前，如果你用了Sa-Token或Spring Security的拦截器，拦截顺序不一致，CORS配置就被前置拦截器档掉了。

我的建议是写一个实现WebMvcConfigurer的类，统一处理跨域映射，而不是单独定义CorsFilter。另外跨域配置的allowedOriginPatterns不要写死为*，因为当你使用携带凭证模式时会直接失效，建议配置为固定的前端地址，比如http://localhost:8081或者部署后的域名。调试的时候把浏览器控制台的报错完整读一遍，里面会直接告诉你哪条策略不满足。

7.2 静态资源404是这五个原因

静态资源404在部署阶段非常常见，尤其是我这种做法，把前端打包后的页面放入src/main/resources/static。一种情况是路径拼接问题，Vue打包后index.html里引用的/static/js/xxx.js路径写的是绝对路径，结果因为后端ContextPath设置的是/house，导致实际访问路径变成了/house/static/js/xxx.js，资源找不到。解决方式是前端构建时的base参数要和后端context-path一致。

另一种情况是打包的时候maven-resources-plugin默认忽略了static目录下的某些文件，比如.css、.js文件明明在，打包进jar却不见了。这种情况在pom.xml里可以检查<resources>节点配置，把src/main/resources整个目录加进去。还有一种情况是浏览器缓存，不是404但页面看起来像旧的，部署完之后在Nginx里配置禁止缓存HTML文件，在SpringBoot里则不需要额外处理，因为每次刷新都会重新请求。

7.3 配置HTTPS之后接口访问变慢怎么办

如果你把系统部署在服务器上，并且用Nginx做了HTTPS代理，会偶尔遇到系统接口变慢的情况。最常见的原因有三个：第一个是Nginx的ssl_protocols、ssl_ciphers配置不合适，导致每次握手无法启用会话缓存，每次请求都要重新协商TLS，妥善配置ssl_session_cache shared:SSL:10m能明显改善；第二个是后端接口本身没有开压缩，单次响应体很大，配上gzip on能解决一大部分；第三个是前端静态资源没有走CDN，图片文件比较大，用户访问首页时全部请求压在一台机器上。

我第一次部署时，最大的感悟是：问题往往不复杂，难的是你愿意一层一层排查下去。HTTPS慢，先确认加密握手是不是瓶颈，再看组件配置，最后看后端逻辑，别上来就怀疑代码买错了服务器。

写到这里，我回忆了一下我最初做房产中介管理系统时踩过的一个看起来特别蠢的坑：数据库主键用了自增ID，前端列表直接把主键暴露在浏览器地址栏里，后面接口虽然做了权限校验，但ID是连续整数，对方只要遍历ID就能探测出平台上一共录入了多少套房源和客户信息，这就是典型的敏感信息泄露。后来改成了雪花ID，虽然不能完全防住恶意爬取，但至少有了一定门槛。像这种真实业务场景里才暴露出来的安全细节，看代码是学不来的。做这类系统，别只顾着把页面做得漂亮、接口写得快，多想想数据在流转的过程中、在部署的边界条件上可能出什么问题，这才是一次真正有长进的项目实践。