企业官网建设流程全解析

我去年帮人拆解过一套基于Spring Boot的房产中介管理系统，从功能设计到数据库表结构、从前端页面到权限控制，前前后后走了不少弯路。今天把整套系统的核心思路和实操细节整理出来，给正在做毕设或想入行Java Web开发的朋友做个参考。

这类系统看似只是一个普通的CRUD项目，但真正动手做起来就会发现，房产中介的业务流远比想象中复杂：房源要区分出售和出租，客户要看房、约看、成交，中介要跟进、回访、签约，合同还要关联房源和客户。再加上管理员的后台审核、统计报表、权限分配，一套完整的系统下来，几乎覆盖了Java Web开发的大部分核心知识点。

这个项目用到的技术栈是Spring Boot + MyBatis Plus + MySQL + Vue/Thymeleaf，典型的Java Web三层架构，前后端分离和传统MVC模式都可以驾驭。适合作为毕业设计、课程设计，或者用于学习Spring Boot整合MyBatis、Redis、权限框架的练手项目。接下来我把整套系统的设计和实现细节拆开讲清楚。

1. 项目整体设计与思路拆解

1.1 为什么是Spring Boot而非传统SSM

很多同学在纠结用传统的SSM框架还是直接用Spring Boot。我说句实在话，现在新开的项目别再碰SSM手写配置了，不是SSM不行，而是Spring Boot把那些繁琐的配置全自动搞定了，开发效率不是一个量级。

这套房产中介系统选择了Spring Boot 2.x版本，原因很简单：

• 内嵌Tomcat，不用外部部署WAR包，一条java -jar命令直接跑起来
• Starter机制一键引入依赖，比如spring-boot-starter-web搞定MVC和嵌入式容器
• 自动配置极大减少了xml配置文件的维护量
• 搭配Spring Boot Actuator可以轻松实现健康检查、监控指标

给你个参考版本组合，我实测过兼容性最好的一套：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent>

为什么用2.x不用3.x？因为很多学校机房、老教程、企业生产环境还在用JDK8，Spring Boot 3.x强制要求JDK17起步，对于毕设和课程设计来说，2.7.x是最稳的选择。当然如果你电脑上已经装了JDK17或者21，直接用3.x也未尝不可，只是注意部分依赖的坐标要换新。

1.2 系统角色与核心模块划分

房产中介系统的核心业务角色很清晰，我看过不少同类项目，角色设计基本都逃不出这三类：

• 管理员：管理所有员工账号、审核房源信息、查看全平台运营数据
• 中介人员（经纪人）：录入房源、管理客户、安排带看、记录跟进、提交成交
• 客户（可选设计）：浏览房源、在线预约看房（如果是前后端分离版，通常会加这个角色）

再往下拆，核心业务模块我画了一张功能脑图：

• 房源管理：录入、编辑、上下架、审核、条件检索（区域、价格区间、户型、面积、租赁/出售）
• 客户管理：客户信息建档、需求登记（是想买房还是租房、预算多少、意向区域）、跟进记录
• 带看管理：创建看房计划、记录看房反馈、带看历史查询
• 合同管理：租售合同创建、条款信息录入、合同金额、生效日期、到期提醒、合同归档
• 统计报表：房源数量统计、成交率、中介业绩排行、区域成交热力图
• 系统管理：员工账号CRUD、角色权限分配、操作日志、数据字典

这里有个设计时的常见误区，很多新手把"带看"和"成交"做成两张互相独立的表，完全没有关联，结果业务数据根本对不上。实际上带看是一条线索，成交是线索的终点，应该通过客户ID和房源ID把两张表串联起来，才能统计出"多少个带看里最终成了一套"。

1.3 技术选型的取舍逻辑

这套系统的后端核心是Spring Boot，持久层我推荐用MyBatis Plus而不是原生MyBatis。原因很实在：原生MyBatis写增删改查要配xml文件、写大量的ResultMap，开发效率低。MyBatis Plus把单表CRUD全部封装好了，自带分页插件、条件构造器、逻辑删除功能，配合Spring Boot几乎零配置接入。

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency>

前端层面，如果你想做前后端分离，用Vue + Element UI是主流；如果不分离，直接使用Thymeleaf模板引擎也是不错的选择。我的建议是：毕设答辩想要视觉效果好，选Vue + Element UI；想省事快速跑通，选Thymeleaf。两者都能做出完整的管理后台风格页面。

数据库MySQL 5.7或8.0都可以，建议直接上8.0，字符集统一utf8mb4，避免中文和emoji乱码。Redis在房产中介系统里不是必选项，但如果要做验证码存储、客户会话管理、热门房源缓存，加上Redis会让项目多一个技术亮点，面试的时候也多一个可聊的点。

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

搞Java Web开发的人心里都有数，一个系统好不好用，最关键的其实是数据库表结构设计。这块设计得好，后面写代码能省一半力气；设计不好，后期补漏洞补到哭。我详细说说这套房产中介系统的表设计思路。

2.1 核心表全景

一张图就能讲清楚系统全貌：

• 用户表（sys_user）：系统登录账号，字段包含用户名、密码（BCrypt加密存储）、真实姓名、手机号、角色ID、状态（启用/禁用）、创建时间
• 角色表（sys_role）：角色编码、角色名称、备注，比如ROLE_ADMIN、ROLE_AGENT
• 房源表（house_info）：房源编号、标题、小区名、区域、地址、户型（室/厅/卫）、面积、楼层、朝向、装修情况、售价/租金、租赁类型（出租/出售）、产权年限、房源状态（待审核/在售/已售/下架）、业主姓名、业主电话、录入人ID、创建时间
• 客户表（customer_info）：客户姓名、电话、身份证号（加密）、客户需求（意向区域、预算范围、期望户型）、客户等级（A/B/C类意向）、来源渠道、归属中介ID、创建时间
• 带看记录表（visit_record）：客户ID、房源ID、中介ID、带看时间、客户反馈、带看状态（已完成/爽约/待定）
• 合同表（contract_info）：合同编号、合同类型（租赁/买卖）、关联客户ID、关联房源ID、关联中介ID、合同金额、成交方式（整租/合租/全款/贷款）、签约日期、生效日期、到期日期、备注
• 跟进记录表（follow_record）：客户/房源ID、跟进内容、下次跟进时间、跟进人
• 操作日志表（sys_log）：操作人、操作模块、操作类型、IP地址、操作详情、操作时间

2.2 房源表设计的几个关键点

房源表的字段比较多，但有几个字段是业务层面的关键要害，设计的时候必须重视。

第一个是房源状态字段。我在表里用status字段做状态流转，常见的取值有0待审核、1在售/在租、2已预约、3已成交、4已下架。为什么单独强调这一点？因为很多新手项目只设计了状态，没有做状态变更的记录，结果用户下架房源后再上架就不知道原因为什么下架、谁下的架。建议加一个audit_record审计记录表，把审核、上下架这类关键操作全部留痕。

第二个是区位信息的设计。城市区域尽量拆成独立的省、市、区/县、商圈四个字段，而不是图省事合成一个"区域地址"字段。因为后续统计报表里需要按区域维度聚合数据，比如"XX区这个月成交了多少套"，如果你存的是整段字符串，SQL的LIKE匹配既慢又不准确。

第三个是业主联系信息脱敏。房源表里存了业主姓名和电话，这涉及个人隐私。合理做法是系统内部存储完整手机号，但在页面展示时只显示前三位后四位，点击查看详情时需要权限校验才能看到完整号码。

CREATE TABLE house_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, house_no VARCHAR(32) NOT NULL COMMENT '房源编号', title VARCHAR(120) COMMENT '房源标题', province VARCHAR(20), city VARCHAR(20), district VARCHAR(20), area_name VARCHAR(50) COMMENT '商圈板块', address_detail VARCHAR(200), rooms INT COMMENT '室', halls INT COMMENT '厅', toilets INT COMMENT '卫', area DOUBLE COMMENT '建筑面积/平方米', floor_num INT, total_floors INT, orientation VARCHAR(10) COMMENT '朝向', decoration VARCHAR(10) COMMENT '装修情况', house_type TINYINT COMMENT '1出售 2出租', price DECIMAL(12,2) COMMENT '售价或月租金', price_unit VARCHAR(10) COMMENT '元/平方米' OR '元/月', status TINYINT DEFAULT 0 COMMENT '0待审核 1在售 2已预约 3已成交 4已下架', owner_name VARCHAR(30), owner_phone VARCHAR(11), create_by BIGINT COMMENT '录入员工ID', create_time DATETIME, update_time DATETIME, deleted TINYINT DEFAULT 0 COMMENT '逻辑删除标记', KEY idx_status_type (status, house_type), KEY idx_district_area (district, area_name) );

这里我额外提一下逻辑删除字段。房产中介系统里的房源、客户、合同都是重要业务数据，用户误删了不可能真的从数据库里抹掉，物理删除风险太高。MyBatis Plus里配置一个@TableLogic注解即可实现逻辑删除，数据库里保留数据，查询时自动过滤已删除的记录。

2.3 关联关系设计

表与表之间的关系，我总结一下这套系统的关联链条：

• 一份房源对应一个录入人，house_info.create_by关联sys_user.id
• 一个客户归属一个经纪人，customer_info.agent_id关联sys_user.id
• 一条带看记录关联一个客户、一个房源、一个经纪人，这是典型的三表关联
• 一份合同关联一个客户和一个房源，同时关联签约的经纪人

在设计的时候，不要为了省事把冗余信息直接塞进一张表，比如在合同表里除了客户ID外再存一份客户姓名和电话，这样做虽然查询方便了，但后续客户信息变更时，历史合同里可能还保留着旧信息，账就对不上。正确的做法是保留关联ID，信息要完整展示时联表查询。

表设计这块，如果你卡住了，我的建议很简单：先把业务里的名词全列出来，每个名词大概率对应一张表；再想清楚每个名词之间的关系，是一对一、一对多还是多对多；最后把字段补齐，把主外键关系理顺。这个流程走一遍，表结构设计不容易出大问题。

3. 核心功能模块的实操拆解

数据库设计好了之后，就到了核心功能编码环节。这里我按业务流把功能模块逐个拆开，每个模块都聊聊具体怎么做、容易踩哪些坑。

3.1 房源管理模块的实现细节

房源管理是最基础也是最重要的模块。增删改查谁都会写，但要做到"实用"就需要在条件检索上下工夫。

房源检索是本系统的高频操作，条件是动态的——用户可能选城市但不选区域，选了区域又指定价格区间，还要按户型过滤。这种动态条件的SQL拼起来会让人很头疼。MyBatis Plus的LambdaQueryWrapper在这一块非常好用：

public Page<HouseInfo> searchHouses(HouseQuery query, Page<HouseInfo> page) { LambdaQueryWrapper<HouseInfo> wrapper = new LambdaQueryWrapper<>(); // 动态拼接条件：区域 wrapper.like(StringUtils.isNotBlank(query.getAreaName()), HouseInfo::getAreaName, query.getAreaName()); // 动态拼接条件：户型（室） wrapper.eq(query.getRooms() != null, HouseInfo::getRooms, query.getRooms()); // 动态拼接条件：价格区间，注意租售价格单位不同 if ("sale".equals(query.getHouseType())) { wrapper.between(query.getMinPrice() != null && query.getMaxPrice() != null, HouseInfo::getPrice, query.getMinPrice(), query.getMaxPrice()); } // 排序：最新发布的排前面 wrapper.orderByDesc(HouseInfo::getCreateTime); // 只查询未删除且在售状态的房源 wrapper.eq(HouseInfo::getStatus, 1); return houseInfoMapper.selectPage(page, wrapper); }

这里有个细节值得留意：like和eq这类条件构造器方法中的第一个布尔参数，是"是否拼接该条件"的判断。这个语法是MyBatis Plus的一大特色，能让你把一堆if判断从Service层里解放出来，代码看起来干净很多。

录入房源时的信息校验也需要注意。@Valid注解配合@NotNull、@NotBlank、@Min、@Max这类约束注解，在Controller接收参数时自动完成校验，不用手写一堆if-else去判断。价格、面积这类业务数值尤为重要，比如价格不能为负数，面积不能为0，录入阶段就把脏数据挡在门外。

3.2 客户管理与跟进记录

客户管理模块的核心不是简单的信息登记，而是跟进记录。房产中介的业务逻辑里，客户从首次咨询到最终成交，中间可能间隔几周甚至几个月，期间经纪人要反复联系、带看、反馈。如果客户管理模块没有跟进功能，那这套系统就是个通讯录而已，毫无业务价值。

跟进记录表的设计要注意两点。一个人是**"下次跟进时间"字段**，这是中介提醒自己继续跟进客户的重要依据。另一个是**"跟进方式"字段**，电话、微信、线下见面，不同触达方式的效果需要留存记录方便复盘。

客户等级的自动转化也是个亮点功能。我见过不少成熟的房产管理系统，客户等级会根据跟进频率和带看次数自动升级。比如：

一个客户在30天内被跟进5次以上，且成功完成2次带看，系统自动将他从C类客户升为B类甚至A类。这个逻辑字段不必刻意放一个等级字段在前端页面让人手动改，可以在后端写一个定时任务或事件触发器，在follow_record插入时同步更新customer_info.level。

3.3 带看流程闭环

带看流程是房产中介业务流程中承上启下的环节：上承客户需求，下启合同成交。系统设计时，我建议做一个三步闭环：

• 创建带看：选择客户、选择房源、设置带看时间，生成带看单
• 记录反馈：带看完成后填写客户反馈，比如"对户型满意，对价格有异议"、"采光不满意"等，同时更新客户需求
• 结果流转：如果客户认可，进入合同签约流程；如果客户不满意，系统自动推荐同小区或同价位的其他房源

这个流程闭环的价值在于，它模拟了中介业务员的真实工作场景。系统不只是"记录"数据，更重要的是"引导"业务推进。我在代码层面做了一个简单推荐逻辑：根据客户意向区域的同小区房源、同价位房源做相似度排序，找出TOP5推荐给中介。这个逻辑不需要引入复杂的推荐算法，简单的SQL条件匹配就够了：

// 根据客户需求推荐房源 LambdaQueryWrapper<HouseInfo> recommendWrapper = new LambdaQueryWrapper<>(); recommendWrapper.eq(HouseInfo::getDistrict, customer.getIntentionDistrict()) .eq(HouseInfo::getHouseType, customer.getIntentionType()) .between(HouseInfo::getPrice, customer.getMinBudget() * 0.9, customer.getMaxBudget() * 1.1) .eq(HouseInfo::getStatus, 1) .orderByDesc(HouseInfo::getCreateTime);

3.4 合同管理与到期提醒

合同模块是房产交易的关键，也是法律效力最强的环节。系统里的合同字段要尽可能完整，除了基本信息外，还应该包括租金/房价支付条款、押金信息（租赁）、贷款方式（买卖）、维修责任划分等。

生成合同编号的规则说一下，常见做法是业务前缀+日期+流水号，比如HT-20240521-001，这样可以保证编号唯一且具有可读性，前端展示时也能直接从编号里看出来大致的签约时间。

合同到期提醒功能是这套系统里比较讨巧的亮点功能。我设计了一个定时任务，每天早上8点扫描即将到期（30天内到期）的合同，给对应的经纪人和管理员发送系统通知。Spring Boot里的实现方案是用@Scheduled注解：

@Component public class ContractRemindTask { @Scheduled(cron = "0 0 8 * * ?") public void remindExpiringContracts() { LocalDate today = LocalDate.now(); LocalDate deadLine = today.plusDays(30); LambdaQueryWrapper<ContractInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.between(ContractInfo::getExpireDate, today, deadLine) .eq(ContractInfo::getStatus, 1); // 1为生效中 List<ContractInfo> contracts = contractInfoMapper.selectList(wrapper); // 遍历通知经纪人... } }

这个模块不复杂，但在答辩时讲出来，"系统具备自动化业务提醒能力"，是个加分项。

4. 权限控制与安全设计

房产中介系统涉及大量业主隐私和员工业务数据，权限控制和安全性是必须重点考虑的部分。

4.1 登录认证与密码安全

用户的密码绝不能明文存储。我在这套系统里使用BCrypt加密，Spring Security自带BCryptPasswordEncoder，也可以直接用commons-lang3里的实现。

登录流程我用的是经典的JWT方案：

• 步骤一：前端提交用户名 + 密码
• 步骤二：后端校验验证码（用Redis存验证码值，有效期5分钟）
• 步骤三：校验用户名密码
• 步骤四：生成JWT Token，返回前端
• 步骤五：前端后续请求在Header里带上Authorization: Bearer <token>
• 步骤六：后端的拦截器解析token、校验有效性、读取用户ID和角色

JWT的核心依赖如下：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>

JWT签发代码大致长这样：

public String createToken(Long userId, String username, String role) { Date now = new Date(); Date expireDate = new Date(now.getTime() + 1000 * 60 * 60 * 24 * 7); return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }

Token时效视项目要求设置，毕设项目7天有效。生产环境一般2-4小时就过期并配合Refresh Token机制刷新，但做学习项目就没必要搞那么复杂。

4.2 基于角色的访问控制

有了JWT认证还不够，还得做授权。我的做法是自定义一个Spring MVC拦截器，在进入Controller之前检查当前用户的角色是否有权限访问某个路径。

拦截器先判断是否为白名单路径（登录接口、验证码接口是白名单），然后再从ThreadLocal里取出当前用户信息做角色判断，处理完业务后在afterCompletion里清理ThreadLocal，避免内存泄漏。

角色层面的控制逻辑很简单：

• 管理员：拥有所有接口的访问权限，后端管理页面可操作一切
• 经纪人：只能操作自己创建的房源、自己名下的客户，create_by必须等于当前用户ID
• 客户（如前端有C端页面）：只能查询公开房源、发起预约、查看自己的预约记录

除了接口层做校验，前端页面也要做按钮级控制，用的是Vue Router的路由守卫和v-if指令。后端是安全底线，前端是体验优化，两层一起做才是完整方案。

4.3 常见Web安全防护

这类管理系统常年暴露在公网，如果安全防护不做，很快就会被扫描攻击。我在项目里做了几层基础防护，供你参考：

• SQL注入：MyBatis的#{}预编译已经防住了大部分SQL注入风险，但要禁止在查询里用${}拼接字符串
• XSS攻击：使用Jsoup对用户提交的富文本内容和字符串进行HTML标签清洗过滤
• 接口限流：基于Redis实现简单的计数器限流，单个IP一分钟内最多调用接口120次，防止恶意刷接口
• 操作日志：使用AOP切面记录登录、房源上下架、合同变更等敏感操作，记录操作人、IP、请求参数，方便事后追溯

操作日志这块，我用一个自定义注解@Log("房源录入")标记在Controller方法上，AOP切面拦截有@Log注解的方法，在其前后执行日志记录逻辑。这个设计很容易实现，还能体现你对系统可维护性的思考。

这里我放一段AOP切面日志记录的框架代码，关键的都有了：

@Aspect @Component public class OperLogAspect { @Autowired private SysLogMapper sysLogMapper; @Around("@annotation(operLog)") public Object around(ProceedingJoinPoint point, OperLog operLog) throws Throwable { long beginTime = System.currentTimeMillis(); Object result = point.proceed(); long time = System.currentTimeMillis() - beginTime; saveLog(point, operLog, time); return result; } private void saveLog(ProceedingJoinPoint joinPoint, OperLog operLog, long time) { // 获取当前登录用户... // 获取请求IP, 当前时间... // 组装SysLog存入数据库 } }

5. 开发部署中的常见问题与避坑实录

这块内容是我实际开发中踩过的坑，一条条整理出来，望各位少走弯路。

5.1 版本冲突是第一大坑

Spring Boot的依赖版本兼容性很关键。2.7.x搭配MyBatis Plus 3.5.x没有大问题，但如果你把Spring Boot升到3.x，旧的MyBatis Plus 3.4.x坐标就不兼容了。最佳实践是去Maven仓库查看依赖的发布时间和适配版本，不要闭着眼睛选最新或最老的。

Apache POI版本也和JDK版本强相关。POI 4.x可以跑在JDK8上，如果你升级JDK17还想用POI 4.x，就会遇到java.lang.NoSuchMethodError这类奇奇怪怪的异常。建议统一用当前最新稳定版，我这边POI用的5.2.5版本，实测稳定。

5.2 数据库连接配置的细节问题

MySQL 8.0的驱动类名和5.7不一样，这是最经典的报错点。5.7的驱动类是com.mysql.jdbc.Driver，8.0换成了com.mysql.cj.jdbc.Driver，如果不改URL和驱动类，启动时会直接报ClassNotFoundException。

MySQL 8.x还强制需要指定时区参数，否则连接时报Server returns invalid timezone错误。URL里加上serverTimezone=Asia/Shanghai和useUnicode=true&characterEncoding=utf8，这两个参数缺一不可。我自己常用的一套配置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/house_agency?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456

5.3 Redis连接与序列化问题

用了Redis就要注意序列化方式。Spring Boot默认的Redis序列化器是JDK序列化，存进去的key会带一堆二进制前缀，在Redis Desktop Manager里看就是乱码。建议显示配置使用StringRedisSerializer（key）和Jackson2JsonRedisSerializer（value）。

另外，如果Redis设置了密码，连接配置里必须明确写上密码，不然会抛ERR Client sent AUTH, but no password is set的错误。这个报错看起来诡异，实际就是密码没配或配错的问题。排查的时候先用命令行工具redis-cli手动执行auth yourpassword验证密码是否正确，再去项目配置里改。

5.4 前端联调的跨域问题

前端Vue跑在localhost:8080，后端Spring Boot跑在localhost:9090，这就出现了跨域。解决跨域的方案很多，最直接的就是在后端加一个全局配置类实现WebMvcConfigurer：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:8080") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

这里有个很大的坑：如果开启了allowCredentials(true)，allowedOrigins不能写成*，必须明确指定具体的源，否则跨域请求会被浏览器拦截。调试跨域问题最省事的方法就是打开浏览器F12，看Network控制台里的具体报错信息，是CORS错误还是401认证错误，错误类型不同排查方向完全不同。

5.5 打包部署需要注意的两件事

Spring Boot项目打包成JAR包后，默认是带内嵌Tomcat的，可以通过java -jar启动。但有一个新手经常遇到的问题：如果别人拿到了你的源码但还没装JDK，快速跑起来的方案是用Maven插件生成可执行包：

mvn clean package java -jar target/house-agency-0.0.1-SNAPSHOT.jar

部署到服务器上时，端口号、数据库地址这些配置不要让用户去改jar包，而是通过外部配置文件覆盖：

java -jar house-agency.jar --spring.config.location=/etc/house/config/application.yml

或者直接通过环境变量覆盖，例如修改端口：

java -jar house-agency.jar --server.port=9090

如果你手头只有编译后的jar包而没有源码，想逆向恢复工程结构，可以使用jd-gui或者fernflower这类反编译工具。把jar包拖进去，源码基本能还原个大概，注意反编译出来的代码没有注释且部分语法会变形，仅适合阅读参考，不适合直接作为工程继续开发。这个需求很多人在做老项目维护时会遇到，说穿了就是"知其然"的手段之一。

5.6 定时任务跑飞了怎么办

@Scheduled定时任务默认是单线程串行执行的。如果你在项目里写了多个定时任务，默认会排队执行，一个任务卡住了其他任务不执行。解决方法是自定义调度线程池的线程数：

@Configuration public class ScheduleConfig implements SchedulingConfigurer { @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(10)); } }

我遇到过合同到期提醒定时任务因为数据库连接超时而中断的情况，排查了半天，最后发现是单线程调度把所有定时任务全卡死在等待中。改成多线程后，各个任务之间互不干扰，问题就消失了。

6. 给新手的一些实操建议

最后多说几句做这类管理系统的心得。

如果你正在准备毕设或者正在学Spring Boot，我的建议是不要上来就照抄开源项目的代码，先自己把ER图画一遍，把用户需求想清楚，再动手写。写代码只占整个项目一半的时间，另一半时间都在填坑和调试。这个房产中介系统看起来很"常规"，但真正做下来，从前端页面到后端口令、从数据表设计到定时任务，每一步都包含了完整的Web开发知识链条。

整个系统我前前后后写了大概6000多行Java代码，算上前端页面和SQL脚本，仔细复盘的话每一步都有不少可优化的空间。比如后续你想在Spring Boot里集成消息队列（ActiveMQ）、文件存储（MinIO）或者告警监控，这个项目都是一个很好的扩展底座。

实操里有两个"小心机"分享给大家。第一个是数据字典：把房源类型、客户等级、带看结果这类固定枚举值统一存一张数据字典表，页面上的下拉选项从字典表动态查询，而不是写死在代码里，这样后续改枚举值不用发版。第二个是导出功能：用Apache POI实现合同信息导出Excel、房源列表导出报表，这种复用性极强的通用导出逻辑，做一个通用方法，全项目都可以调用，也不失为简历上的一个加分项。

还有个小技巧，开发阶段把Spring Boot的启动日志级别调成DEBUG，能帮你快速定位SQL执行、参数绑定、请求映射的问题。上线前再调回INFO，这个操作能省下不少排查问题的时间。

如果你正在做这个系统，卡住了就回头看这三样东西：数据表结构是否合理、MyBatis Plus的条件构造器是否用得正确、Controller的接口路径是否和前端请求对齐。90%的问题出在这三处，剩下的10%，多翻翻官方文档基本也能解决。