做房地产销售管理系统这些年我前前后后接手过好几版从最早的JSPServlet写到SSH再写到Spring Boot感触最深的一点是业务本身并不复杂难的是把“人、房、钱、合同”这四样东西在一个系统里拧成一股绳。Spring Boot的自动配置和生态整合能力恰好把这个过程的开发成本压到了最低。所以今天就想拿“springboot基于JAVA的房地产销售管理系统11765”这个项目当例子把从表结构设计到业务实现、再到排坑优化的全过程拆开揉碎聊一聊。不管你是拿它做毕业设计还是公司里真有楼盘销售管理的需求这篇内容都能给你一个可以直接照着落地的思路。这个系统解决的核心问题很明确房源信息散落在Excel和纸质台账里客户跟进全靠销售个人记忆合同回款对不上账。用一个集中式的管理系统把楼盘、房源、客户、销售员、合同、回款计划统一管起来再配上角色权限和统计看板基本就是房地产销售管理系统的标准形态了。适合正在做Java课程设计或毕业设计的同学也适合刚入行的后端工程师参考企业级项目的真实建模方式。1. 方案选型为什么这个项目绕不开Spring Boot1.1 从Servlet到Spring Boot开发效率差在哪早期做这类管理系统最痛苦的其实是“配置地狱”。web.xml、spring-mvc.xml、mybatis-config.xml、数据源配置、事务配置一套下来光配置文件就够写半天。项目的核心业务逻辑还没开始环境先把人磨掉一层皮。Spring Boot把这种局面彻底扭转了过来。它用自动配置AutoConfiguration替我们完成了大量默认装配引入spring-boot-starter-web内嵌Tomcat直接跑起来引入mybatis-plus-boot-starter数据源和SqlSessionFactory自动完成注册引入spring-boot-starter-validation参数校验注解立刻生效。你只需要关心业务表设计和接口逻辑其余的基础设施被框架“承包”了。对房地产销售管理系统这种典型的CRUD密集型项目来说Spring Boot的另一大优势是管理端UI的快速集成。配合Spring Boot的静态资源映射规则直接把Vue或Thymeleaf构建好的前端丢进resources/static或templates目录就能跑通整链路部署时一个jar包搞定不必像传统项目那样再单独装Tomcat。1.2 为什么业务型系统特别吃这一套我做过的几个管理类系统都有个共同点业务实体多、状态流转细、报表需求杂。房源要从“待售”变为“预订”再变为“已售”客户要区分“意向客户”和“成交客户”合同要关联分期的回款计划。这些逻辑用Spring Boot实现最大的收益是分层规整。Controller层只需要接收参数、调Service、返回统一ResultService层集中处理事务和业务状态流转Mapper层用MyBatis-Plus的BaseMapper获得单表CRUD复杂查询再手写XML。这样一来即使项目扩展到十几个模块代码结构依旧清晰。对毕设答辩或者后续维护来说这种清晰的边界也能省去大量解释成本。提示如果是带着“尽快跑通”的目的做这个项目建议优先把精力放在数据表设计上别一上来就折腾微服务、Redis缓存、消息队列这些进阶组件。表结构稳了业务代码自然好写。2. 核心业务拆解房地产销售系统的对象模型2.1 房源与楼盘先搞清楚“一栋楼”怎么存房源是房地产销售系统的地基。设计表的时候我习惯把“楼盘”和“房源”分开成两张表。楼盘表building记录项目级信息楼盘名称、所在城市、区域、地址、开盘时间、开发商。一张表对应一个真实的地产项目。房源表house则精细到每一套房子所属楼盘ID、楼栋号、单元号、房号、楼层、朝向、建筑面积、户型、单价、总价、销售状态。这里有个特别容易踩坑的点销售状态一定不要用普通字段去存“已售”这种静态文字而应该用数字字典。比如0为未售、1为预订、2为已签约、3为已备案。后面做统计报表、筛选列表的时候数值比较远比字符串比较可靠也方便扩展状态类型。2.2 客户与跟进把销售员的工作流沉淀下来客户模块在一般管理系统里常被简化成一张表但在房地产销售系统里必须拆出“客户主表”和“跟进记录表”。客户主表存基础资料姓名、手机号、证件类型、证件号、意向户型、意向区域、预算范围、客户来源自然到访、渠道推荐、老带新以及归属的销售员ID。跟进记录表则记录每次沟通内容跟进方式电话、微信、到访、沟通摘要、下次跟进时间。这一步很关键——销售管理中最怕的就是“人走单丢”有了跟进记录即使销售员离职客户的联系历史和购买意向也能完整交接给接替者。2.3 合同与回款钱的事一点都不能含糊房地产交易金额大付款方式通常是首付按揭或者一次性的分期付款。所以合同表contract要存合同编号、客户ID、房源ID、成交总价、首付金额、贷款金额、签约时间、合同状态。同时专门建一张回款计划表payment_plan记录每一期的应收日期、应收金额、实收日期、实收金额、收款方式。这个设计的价值在于月末统计“这个月应该回多少款、实际回多少款”时只需要一条SQL对payment_plan按月份汇总即可不需要去合同表里做复杂嵌套计算。3. 数据库设计与代码落地的完整实操3.1 核心表结构设计与字段说明这里给出一套我实际用过的表结构字段都做了精简适合做毕设或者中小型项目直接参考。-- 楼盘表 CREATE TABLE building ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 楼盘名称, city VARCHAR(50) NOT NULL COMMENT 所在城市, district VARCHAR(50) COMMENT 行政区, address VARCHAR(200) COMMENT 详细地址, developer VARCHAR(100) COMMENT 开发商, open_time DATE COMMENT 开盘时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 房源表 CREATE TABLE house ( id BIGINT PRIMARY KEY AUTO_INCREMENT, building_id BIGINT NOT NULL COMMENT 所属楼盘, building_no VARCHAR(20) COMMENT 楼栋号, unit_no VARCHAR(20) COMMENT 单元号, room_no VARCHAR(20) COMMENT 房号, floor_no INT COMMENT 楼层, direction VARCHAR(10) COMMENT 朝向, area DECIMAL(10,2) COMMENT 建筑面积, layout VARCHAR(50) COMMENT 户型如三室两厅, unit_price DECIMAL(12,2) COMMENT 单价, total_price DECIMAL(12,2) COMMENT 总价, status TINYINT DEFAULT 0 COMMENT 0未售 1预订 2已签约 3已备案, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 客户表 CREATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20) NOT NULL, id_type TINYINT DEFAULT 1 COMMENT 1身份证 2护照, id_no VARCHAR(50), intent_layout VARCHAR(50) COMMENT 意向户型, intent_budget DECIMAL(12,2) COMMENT 预算范围, source_type TINYINT COMMENT 1自然到访 2渠道 3老带新, owner_emp_id BIGINT COMMENT 归属销售员, status TINYINT DEFAULT 0 COMMENT 客户状态0意向 1成交 2流失, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 跟进记录表 CREATE TABLE follow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL, emp_id BIGINT NOT NULL COMMENT 跟进人, follow_type TINYINT COMMENT 1电话 2微信 3到访, content VARCHAR(500) COMMENT 跟进摘要, next_time DATETIME COMMENT 下次跟进时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 合同表 CREATE TABLE contract ( id BIGINT PRIMARY KEY AUTO_INCREMENT, contract_no VARCHAR(50) UNIQUE NOT NULL COMMENT 合同编号, customer_id BIGINT NOT NULL, house_id BIGINT NOT NULL, emp_id BIGINT NOT NULL COMMENT 置业顾问, total_amount DECIMAL(14,2) NOT NULL, down_payment DECIMAL(14,2) COMMENT 首付金额, loan_amount DECIMAL(14,2) COMMENT 贷款金额, sign_time DATE COMMENT 签约日期, status TINYINT DEFAULT 0 COMMENT 0草稿 1生效 2作废, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 回款计划表 CREATE TABLE payment_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, contract_id BIGINT NOT NULL, period_no INT COMMENT 期数, due_date DATE COMMENT 应收日期, due_amount DECIMAL(14,2) COMMENT 应收金额, paid_date DATE COMMENT 实收日期, paid_amount DECIMAL(14,2) COMMENT 实收金额, pay_type TINYINT COMMENT 1现金 2转账 3刷卡, status TINYINT DEFAULT 0 COMMENT 0待支付 1已支付 2逾期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );3.2 三件套实体、Mapper、Service的编码示范实体类直接用MyBatis-Plus注解开发简洁省事Data TableName(house) public class House { TableId(type IdType.AUTO) private Long id; private Long buildingId; private String buildingNo; private String unitNo; private String roomNo; private Integer floorNo; private String direction; private BigDecimal area; private String layout; private BigDecimal unitPrice; private BigDecimal totalPrice; private Integer status; }Service层处理状态流转时要注意加事务注解。比如预定时要同时改房源状态、写入客户信息、创建跟进记录三步不能分开提交。Service public class HouseServiceImpl implements HouseService { Autowired private HouseMapper houseMapper; Autowired private CustomerMapper customerMapper; Autowired private FollowRecordMapper followRecordMapper; Override Transactional(rollbackFor Exception.class) public void reserveHouse(ReserveRequest request) { House house houseMapper.selectById(request.getHouseId()); if (house null || house.getStatus() ! 0) { throw new BusinessException(房源不存在或不可预订); } // 乐观锁更新房源状态 house.setStatus(1); int updated houseMapper.updateById(house); if (updated 0) { throw new BusinessException(该房源已被其他客户抢先预订); } // 新增客户信息 Customer customer new Customer(); customer.setName(request.getCustomerName()); customer.setPhone(request.getCustomerPhone()); customerMapper.insert(customer); // 写入跟进记录 FollowRecord record new FollowRecord(); record.setCustomerId(customer.getId()); record.setEmpId(request.getEmpId()); record.setContent(request.getFollowContent()); followRecordMapper.insert(record); } }3.3 Controller层与统一返回结果Controller层尽量薄参数校验交给注解处理。我习惯封装一个Result类所有接口统一返回code、message、data三个字段前端判断code是否等于200即可。RestController RequestMapping(/api/house) public class HouseController { Autowired private HouseService houseService; GetMapping(/list) public Result list(RequestParam(required false) Long buildingId, RequestParam(required false) Integer status, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(houseService.pageQuery(buildingId, status, pageNum, pageSize)); } PostMapping(/reserve) public Result reserve(RequestBody Validated ReserveRequest request) { houseService.reserveHouse(request); return Result.success(); } }注意参数校验的请求类上面一定要加Validated注解否则Spring Boot的校验框架不会触发NotBlank、NotNull这些注解形同虚设。这个问题我见过太多人踩。4. 开发过程中最常踩的坑与排查实录4.1 MyBatis-Plus分页插件导致total始终为0这个坑绝大多数人都能遇到。分页插件需要显式配置一个PaginationInnerInterceptor否则Page对象能查出来当前页数据但total字段一直是0前端分页组件就变成“只有一页”翻不了页。解决方案是在配置类里注册插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }另外自定义SQL分页时必须把IPage作为方法的第一个参数写进Mapper接口MyBatis-Plus才自动完成count查询和limit拼接。4.2 事务回滚不生效的三种隐蔽情况第一种是方法内部自调用。同一个类里的A方法调用B方法B上有Transactional但因为绕过代理对象事务根本不会创建。解决办法是把B方法挪到另一个Service里或者注入自身。第二种是异常被吞掉。很多人习惯在Service里try-catch后打印日志但catch住了异常又没抛出事务管理器压根感知不到自然不回滚。统一做法是业务异常转换为自定义BusinessException向上抛出事务边界交给最外层统一处理。第三种是事务注解加在private方法上。Spring的AOP代理对private方法不生效Transactional必须放在public方法上才有实际意义。4.3 前后端分离的Token校验与跨域问题房地产销售系统通常有管理端和销售端两种角色登录认证我用JWT配合拦截器实现。前端每次请求带上Authorization头后端写一个HandlerInterceptor统一校验Token并把用户信息放进ThreadLocal变量里后续业务方法直接读取当前操作人ID即可。跨域问题则统一交给CorsFilter处理注意allowedOriginPatterns不要用通配因为allowCredentials设置为true时Spring Boot不允许origin为的组合必须使用具体的域名模式或allowedOriginPatterns。Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); }4.4 金额计算为什么不能用Double房源总价、合同金额、回款计划这些字段一定要用BigDecimal或者数据库层面直接用DECIMAL类型。Double在二进制浮点运算下会产生产精度丢失比如0.10.2计算结果是0.30000000000000004。涉及钱的地方一旦出现这种误差实际对账时就是大麻烦。实操心得Java侧使用BigDecimal时构造方法要传字符串而不是数字即new BigDecimal(19999.99)避免浮点转换带来的精度问题。5. 项目进阶优化与个人经验总结5.1 还能加什么功能让项目更有竞争力基础CRUD做完之后这个系统距离“能拿出手”还差几个亮点功能。统计看板是最值得优先做的。用一张dashboard页展示各楼盘的房源去化率、本月回款金额、客户转化率、销售员业绩排名。实现上可以写几个带GROUP BY的统计SQL配合ECharts或Vue的图表组件渲染。答辩或汇报时一个可视化的数据面板比一百行代码更能说明项目价值。其次是消息通知。客户跟进到期提醒、回款日期到期提醒都可以用Spring Boot自带的定时任务Scheduled实现。每天凌晨扫描一次next_time和due_date把待办事项推送给对应销售员。这一步不需要引入消息队列简单实用。再做深一点可以用EasyExcel导出客户列表、合同台账和回款明细。房地产销售行业对Excel的需求极高导出功能一旦有整个系统的可用性会明显上一个台阶。5.2 我对这套系统的几个操作体会前后做过的几个版本沉淀下来几条心得。第一状态字段不要设计成字符串枚举散落在代码各处最好单独建一张字典表或者在实体定义里用常量类统一管理。我见过有人把“未售”“已售”直接写死在SQL里后来需求变了全项目查找替换改了两小时。第二房源编号、合同编号这类业务编号别用数据库自增ID最好生成有规则的编号比如合同号取“HT 年月日 流水号”。数据库自增ID会泄露业务规模而且不方便人工识别。第三做这类系统时我最看重字段级别的职责单一。比如客户来源、跟进方式、付款方式这些枚举值单独建一张小表管理反而比写死在代码里更好维护。哪怕临时加一个“抖音渠道”数据库插入一条记录就能生效不用发版。如果你正在写这个项目我的建议是先把业务流程图理顺再动手写表。房屋状态怎么走、客户怎么跟进、合同怎么回款这三条主线想清楚项目就等于完成了七成。剩下的编码其实就是把已经设计好的业务规则翻译成Spring Boot的Service和Mapper而已。 
长河君 · 2026/10/12 23:46:59 · 阅读 1.2k Spring Boot房地产销售管理系统开发实战与设计解析
做房地产销售管理系统这些年我前前后后接手过好几版从最早的JSPServlet写到SSH再写到Spring Boot感触最深的一点是业务本身并不复杂难的是把“人、房、钱、合同”这四样东西在一个系统里拧成一股绳。Spring Boot的自动配置和生态整合能力恰好把这个过程的开发成本压到了最低。所以今天就想拿“springboot基于JAVA的房地产销售管理系统11765”这个项目当例子把从表结构设计到业务实现、再到排坑优化的全过程拆开揉碎聊一聊。不管你是拿它做毕业设计还是公司里真有楼盘销售管理的需求这篇内容都能给你一个可以直接照着落地的思路。这个系统解决的核心问题很明确房源信息散落在Excel和纸质台账里客户跟进全靠销售个人记忆合同回款对不上账。用一个集中式的管理系统把楼盘、房源、客户、销售员、合同、回款计划统一管起来再配上角色权限和统计看板基本就是房地产销售管理系统的标准形态了。适合正在做Java课程设计或毕业设计的同学也适合刚入行的后端工程师参考企业级项目的真实建模方式。1. 方案选型为什么这个项目绕不开Spring Boot1.1 从Servlet到Spring Boot开发效率差在哪早期做这类管理系统最痛苦的其实是“配置地狱”。web.xml、spring-mvc.xml、mybatis-config.xml、数据源配置、事务配置一套下来光配置文件就够写半天。项目的核心业务逻辑还没开始环境先把人磨掉一层皮。Spring Boot把这种局面彻底扭转了过来。它用自动配置AutoConfiguration替我们完成了大量默认装配引入spring-boot-starter-web内嵌Tomcat直接跑起来引入mybatis-plus-boot-starter数据源和SqlSessionFactory自动完成注册引入spring-boot-starter-validation参数校验注解立刻生效。你只需要关心业务表设计和接口逻辑其余的基础设施被框架“承包”了。对房地产销售管理系统这种典型的CRUD密集型项目来说Spring Boot的另一大优势是管理端UI的快速集成。配合Spring Boot的静态资源映射规则直接把Vue或Thymeleaf构建好的前端丢进resources/static或templates目录就能跑通整链路部署时一个jar包搞定不必像传统项目那样再单独装Tomcat。1.2 为什么业务型系统特别吃这一套我做过的几个管理类系统都有个共同点业务实体多、状态流转细、报表需求杂。房源要从“待售”变为“预订”再变为“已售”客户要区分“意向客户”和“成交客户”合同要关联分期的回款计划。这些逻辑用Spring Boot实现最大的收益是分层规整。Controller层只需要接收参数、调Service、返回统一ResultService层集中处理事务和业务状态流转Mapper层用MyBatis-Plus的BaseMapper获得单表CRUD复杂查询再手写XML。这样一来即使项目扩展到十几个模块代码结构依旧清晰。对毕设答辩或者后续维护来说这种清晰的边界也能省去大量解释成本。提示如果是带着“尽快跑通”的目的做这个项目建议优先把精力放在数据表设计上别一上来就折腾微服务、Redis缓存、消息队列这些进阶组件。表结构稳了业务代码自然好写。2. 核心业务拆解房地产销售系统的对象模型2.1 房源与楼盘先搞清楚“一栋楼”怎么存房源是房地产销售系统的地基。设计表的时候我习惯把“楼盘”和“房源”分开成两张表。楼盘表building记录项目级信息楼盘名称、所在城市、区域、地址、开盘时间、开发商。一张表对应一个真实的地产项目。房源表house则精细到每一套房子所属楼盘ID、楼栋号、单元号、房号、楼层、朝向、建筑面积、户型、单价、总价、销售状态。这里有个特别容易踩坑的点销售状态一定不要用普通字段去存“已售”这种静态文字而应该用数字字典。比如0为未售、1为预订、2为已签约、3为已备案。后面做统计报表、筛选列表的时候数值比较远比字符串比较可靠也方便扩展状态类型。2.2 客户与跟进把销售员的工作流沉淀下来客户模块在一般管理系统里常被简化成一张表但在房地产销售系统里必须拆出“客户主表”和“跟进记录表”。客户主表存基础资料姓名、手机号、证件类型、证件号、意向户型、意向区域、预算范围、客户来源自然到访、渠道推荐、老带新以及归属的销售员ID。跟进记录表则记录每次沟通内容跟进方式电话、微信、到访、沟通摘要、下次跟进时间。这一步很关键——销售管理中最怕的就是“人走单丢”有了跟进记录即使销售员离职客户的联系历史和购买意向也能完整交接给接替者。2.3 合同与回款钱的事一点都不能含糊房地产交易金额大付款方式通常是首付按揭或者一次性的分期付款。所以合同表contract要存合同编号、客户ID、房源ID、成交总价、首付金额、贷款金额、签约时间、合同状态。同时专门建一张回款计划表payment_plan记录每一期的应收日期、应收金额、实收日期、实收金额、收款方式。这个设计的价值在于月末统计“这个月应该回多少款、实际回多少款”时只需要一条SQL对payment_plan按月份汇总即可不需要去合同表里做复杂嵌套计算。3. 数据库设计与代码落地的完整实操3.1 核心表结构设计与字段说明这里给出一套我实际用过的表结构字段都做了精简适合做毕设或者中小型项目直接参考。-- 楼盘表 CREATE TABLE building ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 楼盘名称, city VARCHAR(50) NOT NULL COMMENT 所在城市, district VARCHAR(50) COMMENT 行政区, address VARCHAR(200) COMMENT 详细地址, developer VARCHAR(100) COMMENT 开发商, open_time DATE COMMENT 开盘时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 房源表 CREATE TABLE house ( id BIGINT PRIMARY KEY AUTO_INCREMENT, building_id BIGINT NOT NULL COMMENT 所属楼盘, building_no VARCHAR(20) COMMENT 楼栋号, unit_no VARCHAR(20) COMMENT 单元号, room_no VARCHAR(20) COMMENT 房号, floor_no INT COMMENT 楼层, direction VARCHAR(10) COMMENT 朝向, area DECIMAL(10,2) COMMENT 建筑面积, layout VARCHAR(50) COMMENT 户型如三室两厅, unit_price DECIMAL(12,2) COMMENT 单价, total_price DECIMAL(12,2) COMMENT 总价, status TINYINT DEFAULT 0 COMMENT 0未售 1预订 2已签约 3已备案, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 客户表 CREATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20) NOT NULL, id_type TINYINT DEFAULT 1 COMMENT 1身份证 2护照, id_no VARCHAR(50), intent_layout VARCHAR(50) COMMENT 意向户型, intent_budget DECIMAL(12,2) COMMENT 预算范围, source_type TINYINT COMMENT 1自然到访 2渠道 3老带新, owner_emp_id BIGINT COMMENT 归属销售员, status TINYINT DEFAULT 0 COMMENT 客户状态0意向 1成交 2流失, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 跟进记录表 CREATE TABLE follow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL, emp_id BIGINT NOT NULL COMMENT 跟进人, follow_type TINYINT COMMENT 1电话 2微信 3到访, content VARCHAR(500) COMMENT 跟进摘要, next_time DATETIME COMMENT 下次跟进时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 合同表 CREATE TABLE contract ( id BIGINT PRIMARY KEY AUTO_INCREMENT, contract_no VARCHAR(50) UNIQUE NOT NULL COMMENT 合同编号, customer_id BIGINT NOT NULL, house_id BIGINT NOT NULL, emp_id BIGINT NOT NULL COMMENT 置业顾问, total_amount DECIMAL(14,2) NOT NULL, down_payment DECIMAL(14,2) COMMENT 首付金额, loan_amount DECIMAL(14,2) COMMENT 贷款金额, sign_time DATE COMMENT 签约日期, status TINYINT DEFAULT 0 COMMENT 0草稿 1生效 2作废, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 回款计划表 CREATE TABLE payment_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, contract_id BIGINT NOT NULL, period_no INT COMMENT 期数, due_date DATE COMMENT 应收日期, due_amount DECIMAL(14,2) COMMENT 应收金额, paid_date DATE COMMENT 实收日期, paid_amount DECIMAL(14,2) COMMENT 实收金额, pay_type TINYINT COMMENT 1现金 2转账 3刷卡, status TINYINT DEFAULT 0 COMMENT 0待支付 1已支付 2逾期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );3.2 三件套实体、Mapper、Service的编码示范实体类直接用MyBatis-Plus注解开发简洁省事Data TableName(house) public class House { TableId(type IdType.AUTO) private Long id; private Long buildingId; private String buildingNo; private String unitNo; private String roomNo; private Integer floorNo; private String direction; private BigDecimal area; private String layout; private BigDecimal unitPrice; private BigDecimal totalPrice; private Integer status; }Service层处理状态流转时要注意加事务注解。比如预定时要同时改房源状态、写入客户信息、创建跟进记录三步不能分开提交。Service public class HouseServiceImpl implements HouseService { Autowired private HouseMapper houseMapper; Autowired private CustomerMapper customerMapper; Autowired private FollowRecordMapper followRecordMapper; Override Transactional(rollbackFor Exception.class) public void reserveHouse(ReserveRequest request) { House house houseMapper.selectById(request.getHouseId()); if (house null || house.getStatus() ! 0) { throw new BusinessException(房源不存在或不可预订); } // 乐观锁更新房源状态 house.setStatus(1); int updated houseMapper.updateById(house); if (updated 0) { throw new BusinessException(该房源已被其他客户抢先预订); } // 新增客户信息 Customer customer new Customer(); customer.setName(request.getCustomerName()); customer.setPhone(request.getCustomerPhone()); customerMapper.insert(customer); // 写入跟进记录 FollowRecord record new FollowRecord(); record.setCustomerId(customer.getId()); record.setEmpId(request.getEmpId()); record.setContent(request.getFollowContent()); followRecordMapper.insert(record); } }3.3 Controller层与统一返回结果Controller层尽量薄参数校验交给注解处理。我习惯封装一个Result类所有接口统一返回code、message、data三个字段前端判断code是否等于200即可。RestController RequestMapping(/api/house) public class HouseController { Autowired private HouseService houseService; GetMapping(/list) public Result list(RequestParam(required false) Long buildingId, RequestParam(required false) Integer status, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(houseService.pageQuery(buildingId, status, pageNum, pageSize)); } PostMapping(/reserve) public Result reserve(RequestBody Validated ReserveRequest request) { houseService.reserveHouse(request); return Result.success(); } }注意参数校验的请求类上面一定要加Validated注解否则Spring Boot的校验框架不会触发NotBlank、NotNull这些注解形同虚设。这个问题我见过太多人踩。4. 开发过程中最常踩的坑与排查实录4.1 MyBatis-Plus分页插件导致total始终为0这个坑绝大多数人都能遇到。分页插件需要显式配置一个PaginationInnerInterceptor否则Page对象能查出来当前页数据但total字段一直是0前端分页组件就变成“只有一页”翻不了页。解决方案是在配置类里注册插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }另外自定义SQL分页时必须把IPage作为方法的第一个参数写进Mapper接口MyBatis-Plus才自动完成count查询和limit拼接。4.2 事务回滚不生效的三种隐蔽情况第一种是方法内部自调用。同一个类里的A方法调用B方法B上有Transactional但因为绕过代理对象事务根本不会创建。解决办法是把B方法挪到另一个Service里或者注入自身。第二种是异常被吞掉。很多人习惯在Service里try-catch后打印日志但catch住了异常又没抛出事务管理器压根感知不到自然不回滚。统一做法是业务异常转换为自定义BusinessException向上抛出事务边界交给最外层统一处理。第三种是事务注解加在private方法上。Spring的AOP代理对private方法不生效Transactional必须放在public方法上才有实际意义。4.3 前后端分离的Token校验与跨域问题房地产销售系统通常有管理端和销售端两种角色登录认证我用JWT配合拦截器实现。前端每次请求带上Authorization头后端写一个HandlerInterceptor统一校验Token并把用户信息放进ThreadLocal变量里后续业务方法直接读取当前操作人ID即可。跨域问题则统一交给CorsFilter处理注意allowedOriginPatterns不要用通配因为allowCredentials设置为true时Spring Boot不允许origin为的组合必须使用具体的域名模式或allowedOriginPatterns。Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); }4.4 金额计算为什么不能用Double房源总价、合同金额、回款计划这些字段一定要用BigDecimal或者数据库层面直接用DECIMAL类型。Double在二进制浮点运算下会产生产精度丢失比如0.10.2计算结果是0.30000000000000004。涉及钱的地方一旦出现这种误差实际对账时就是大麻烦。实操心得Java侧使用BigDecimal时构造方法要传字符串而不是数字即new BigDecimal(19999.99)避免浮点转换带来的精度问题。5. 项目进阶优化与个人经验总结5.1 还能加什么功能让项目更有竞争力基础CRUD做完之后这个系统距离“能拿出手”还差几个亮点功能。统计看板是最值得优先做的。用一张dashboard页展示各楼盘的房源去化率、本月回款金额、客户转化率、销售员业绩排名。实现上可以写几个带GROUP BY的统计SQL配合ECharts或Vue的图表组件渲染。答辩或汇报时一个可视化的数据面板比一百行代码更能说明项目价值。其次是消息通知。客户跟进到期提醒、回款日期到期提醒都可以用Spring Boot自带的定时任务Scheduled实现。每天凌晨扫描一次next_time和due_date把待办事项推送给对应销售员。这一步不需要引入消息队列简单实用。再做深一点可以用EasyExcel导出客户列表、合同台账和回款明细。房地产销售行业对Excel的需求极高导出功能一旦有整个系统的可用性会明显上一个台阶。5.2 我对这套系统的几个操作体会前后做过的几个版本沉淀下来几条心得。第一状态字段不要设计成字符串枚举散落在代码各处最好单独建一张字典表或者在实体定义里用常量类统一管理。我见过有人把“未售”“已售”直接写死在SQL里后来需求变了全项目查找替换改了两小时。第二房源编号、合同编号这类业务编号别用数据库自增ID最好生成有规则的编号比如合同号取“HT 年月日 流水号”。数据库自增ID会泄露业务规模而且不方便人工识别。第三做这类系统时我最看重字段级别的职责单一。比如客户来源、跟进方式、付款方式这些枚举值单独建一张小表管理反而比写死在代码里更好维护。哪怕临时加一个“抖音渠道”数据库插入一条记录就能生效不用发版。如果你正在写这个项目我的建议是先把业务流程图理顺再动手写表。房屋状态怎么走、客户怎么跟进、合同怎么回款这三条主线想清楚项目就等于完成了七成。剩下的编码其实就是把已经设计好的业务规则翻译成Spring Boot的Service和Mapper而已。