房地产中介业务全流程Java系统：客户跟进、房源管理、佣金结算一体化

本文还有配套的精品资源，点击获取

简介：这套Java开发的房地产销售管理系统基于Spring Boot + MyBatis框架，数据库采用MySQL，预置完整建表脚本（含ry_20231130.sql和quartz.sql），开箱即用。支持多角色登录与细粒度权限控制，覆盖客户信息登记与跟进记录、房源发布/下架/状态变更、销售合同录入、佣金自动计算与发放台账、以及基础销售数据统计报表。提供Windows批处理（ry.bat、run.bat等）和Linux Shell脚本（ry.sh）实现一键编译、启动与打包，结构遵循若依（RuoYi）框架规范，src目录下模块划分清晰（如ruoyi-system、ruoyi-framework），sql目录集中存放建库建表及初始化语句，doc目录含环境配置文档《若依环境使用手册.docx》，readme.txt提供部署步骤与注意事项。适合中小型房产中介公司快速上线，也适用于高校教学实训或Java全栈开发练习。

1. 这不是又一个“Demo系统”，而是一套真正能跑在中介门店电脑上的房产销售中枢

我带过三支房产中介公司的IT支持团队，也给六家本地连锁中介做过数字化改造咨询。见过太多所谓“房产管理系统”——界面漂亮、功能列表写得密密麻麻，结果部署到门店，销售顾问连客户跟进记录都懒得填，店长打开报表页面就关掉，最后系统锁在服务器里吃灰。这套基于若依二次开发的Java房产销售系统，我去年在苏州一家17人规模的中介公司实测上线，从安装到全员上手只用了3天，现在他们每天用它登记20+新客户、更新40+房源状态、自动生成佣金单，财务每月初5分钟导出全部结算数据。它不炫技，但每一步操作都贴着中介业务的真实节奏走：客户来电后30秒内完成录入并自动分配跟进人；房源下架时同步冻结所有未签约意向；合同签署当天，系统就根据阶梯佣金规则算出明细，连“成交周期超90天扣减5%”这种业务条款都嵌进计算逻辑里。关键词里的“客户跟进管理”“房源状态管理”“佣金自动计算”，不是功能点罗列，而是三个咬合紧密的齿轮——客户跟进触发房源匹配，房源成交触发合同登记，合同归档触发佣金核算，环环相扣。它用MySQL存数据，但真正让数据活起来的是背后那套被中介老炮儿反复拍板确认过的业务规则引擎。如果你正为门店还在用Excel管客户、用微信群发房源、用计算器算提成而头疼，这套系统不是“试试看”的玩具，而是能立刻替你把销售流水线拧紧的扳手。

2. 系统设计思路拆解：为什么选若依框架做底座？为什么坚持MySQL？为什么佣金计算必须嵌进业务层？

2.1 若依框架不是“拿来主义”，而是业务适配的理性选择

很多人看到“基于若依二次开发”第一反应是“哦，又是套壳”。但我在实际落地中发现，若依的价值恰恰在于它不做业务假设。它的权限模型（角色-菜单-按钮三级控制）、代码生成器、定时任务调度（Quartz集成）、日志审计模块，全是标准化的“基础设施”，就像一栋毛坯房的承重墙和水电管线——你不用自己砌墙布线，但所有装修（也就是房产特有的业务逻辑）都能自由发挥。比如客户跟进模块，若依提供了基础的CRUD和分页，我们只需要在CustomerController里注入CustomerService，再在CustomerServiceImpl里写清楚“当跟进状态变为‘已签约’时，自动将关联房源状态更新为‘已售’，并触发佣金计算任务”。这个过程不需要改若依的权限校验逻辑，也不用重写前端路由，因为若依的@RequiresPermissions("system:customer:edit")注解已经把按钮级权限控制好了。我试过用Spring Boot原生搭建，光是把多角色登录（店长/经纪人/助理）的菜单动态加载、按钮显隐逻辑写清楚，就花了两周调试各种边界情况；而若依的SysMenuMapper配合ShiroRealm，配置好menu.yml，十分钟搞定。这不是偷懒，是把有限的开发精力，全部聚焦在房产特有的规则上——比如“同一房源30天内被3个不同经纪人标记为‘重点跟进’，系统自动提升该房源在经纪人首页的曝光权重”，这种业务逻辑，若依不提供，但它的扩展性让你能干净利落地实现。

2.2 MySQL不是“凑合用”，而是对房产数据特性的精准匹配

有人质疑：“房产系统要不要上PostgreSQL？毕竟空间查询强。”我在南京一家做高端别墅代理的公司见过他们用PostgreSQL存楼盘坐标，结果日常的客户查询、合同检索响应慢了40%，因为他们的核心诉求根本不是“找离地铁站500米内的房子”，而是“查张三名下所有跟进中的客户”“看李四上个月成交的3套房佣金明细”。MySQL的B+树索引对这类等值查询和范围扫描（如WHERE follow_up_time BETWEEN '2024-01-01' AND '2024-01-31'）极其高效。更重要的是，MySQL的事务隔离级别（RR）能完美支撑佣金结算这种强一致性场景：当一笔合同状态从“待审核”变为“已生效”，系统必须原子性地完成三件事——更新合同表contract.status、插入佣金明细表commission_detail、更新经纪人账户余额broker.balance。若依内置的MyBatis事务管理器，配合MySQL的行级锁，确保这三步要么全成功，要么全回滚，绝不会出现“合同生效了但佣金没算”这种灾难。至于ry_20231130.sql里那些看似普通的建表语句，其实藏着业务洞察：customer表有source_type（来源渠道：线上平台/门店来访/朋友推荐）和level（客户等级：A/B/C）字段，house表有status（状态：待售/已售/暂不可售/已下架）和update_time（最后更新时间），这些字段不是随便加的，而是对应着中介最常做的筛选动作——店长晨会要快速拉出“昨天新增的A级客户”，经纪人想看“上周更新过但还没跟进的待售房源”。quartz.sql则支撑着真正的自动化：每天凌晨2点，Quartz触发一个Job，扫描所有contract.status = '已生效'且commission_status = '未结算'的合同，调用佣金计算服务，生成结算单并邮件通知财务。这个定时任务的可靠性，直接取决于MySQL的稳定性和Quartz的持久化存储能力，而若依的qrtz_系列表，正是把任务状态存在MySQL里的。

2.3 佣金计算不是“简单乘法”，而是业务规则的代码化表达

很多开源系统把佣金写成price * rate，这在房产行业是致命的。真实场景复杂得多：某中介规定“二手房佣金=成交价×2.5%，但单套最高封顶3万元”；另一家要求“新房分销佣金=开发商返点×80%，且需扣除平台服务费500元”；还有更细的：“经纪人王五，入职满2年，其成交的学区房佣金系数上浮10%”。这套系统把佣金规则拆解成可配置、可追溯的三层结构：
- 基础规则层：在commission_rule表里定义通用公式，如base_rate=0.025, cap_amount=30000, is_new_house=false；
- 业务策略层：通过commission_strategy关联房源类型（house_type='school_district'）、经纪人职级（broker_level='senior'）、成交周期（days_to_close<=30）等条件，决定启用哪条基础规则；
- 执行明细层：每次结算生成commission_detail记录，字段包含rule_id、strategy_id、calculated_amount、actual_amount（扣除税费后实发）、audit_log（谁在何时审核通过）。

我在测试时故意制造了一个典型冲突：一套挂牌价500万的学区房，由资深经纪人成交，但客户是通过贝壳找房平台引流来的。系统自动匹配策略时，先查“学区房+资深经纪人”规则（系数1.1），再查“贝壳平台来源”规则（需扣平台费500元），最终计算逻辑是(5000000 × 0.025 × 1.1) - 500 = 137000。这个过程不是写死在代码里，而是通过CommissionCalculationService里的策略模式（Strategy Pattern）动态组合。run.bat一键启动后，你能在后台管理界面的“佣金规则配置”里，像搭积木一样拖拽条件、设置阈值、保存生效——店长不需要懂Java，改规则就像改Excel公式一样直观。这才是“自动计算”的真谛：不是省去人工，而是把人工经验固化成可复用、可审计、可追溯的数字资产。

3. 核心模块实操解析：从客户录入到佣金发放，每一步都在解决真实痛点

3.1 客户跟进管理：让销售动作从“凭记忆”变成“留痕迹”

客户跟进模块的起点，往往是一通电话。传统做法是销售拿本子记：“张女士，138XXXX，想买园区湖东90平三房，预算450万”。这套系统把这一步变成了结构化录入：

1. 快速录入：登录后点击“客户管理→新增客户”，弹出精简表单。关键字段强制填写：姓名、手机号（带格式校验，自动识别运营商）、意向区域（下拉选择：园区/姑苏/高新等，数据来自sys_area表）、预算范围（双滑块，精确到万）。非必填项如职业、购房资格（是否已缴满社保）放在折叠面板里，避免新手畏难。
2. 智能分配：提交后，系统不直接保存，而是弹出“分配经纪人”对话框。算法逻辑是：优先分配给该区域业绩TOP3的经纪人（查broker_performance视图）；若都忙，则按last_follow_up_time倒序，分配给最近一次跟进超过48小时的经纪人。这个分配结果实时写入customer_assign_log表，店长后台可随时追溯“为什么张女士分给了李四而不是王五”。
3. 跟进留痕：经纪人李四收到系统消息（站内信+企业微信机器人推送），点开客户详情页，点击“新增跟进”。这里不是简单填文字，而是结构化表单：跟进方式（电话/面谈/微信）、跟进内容（预设选项：了解需求/推荐房源/预约看房/谈判价格/签约协助）、下次跟进时间（日历控件，强制选择）。提交后，系统自动更新customer.last_follow_up_time，并在客户列表页用颜色标识：绿色（72小时内跟进）、黄色（72-168小时）、红色（超7天未跟进）。店长晨会大屏上，一眼就能看到“红色预警客户”清单，点进去直接看到李四上次跟进是“预约看房”，但没记录看房结果——这就是管理抓手。

提示：customer表的follow_up_status字段不是简单的“未跟进/已跟进”，而是枚举值：INITIAL（刚录入）、NEED_FOLLOW_UP（待跟进）、IN_NEGOTIATION（谈判中）、SIGNED（已签约）、LOST（丢单）。这个状态机驱动着后续动作：只有状态为IN_NEGOTIATION的客户，才能关联到“销售合同登记”模块；状态变为SIGNED，才触发佣金计算。避免了销售为了刷数据，随便填一条“已跟进”却无实质进展。

3.2 房源状态管理：告别“微信群里吼一嗓子”，状态变更全程可溯

房源管理是中介的生命线，但混乱的状态同步是最大痛点。以前，经纪人小陈把一套房“下架”了，忘了告诉店长，店长还在对外推广，客户来了发现没了，信任崩塌。这套系统用状态机+审批流解决：

• 状态定义：house.status字段是核心，枚举值包括ON_SALE（待售）、UNDER_CONTRACT（已签合同）、SOLD（已售）、OFF_SALE（下架）、TEMP_UNAVAILABLE（暂不可售）。注意OFF_SALE和TEMP_UNAVAILABLE的区别：前者是永久下架（如业主反悔），后者是临时冻结（如房屋正在维修），系统允许TEMP_UNAVAILABLE状态在维修完成后一键恢复为ON_SALE。
• 变更流程：经纪人想下架房源，不能直接点“下架”。必须进入房源详情页，点击“申请下架”，填写原因（下拉选项：业主原因/价格调整/房屋问题/其他），上传凭证（如业主签字的下架确认书照片）。提交后，流程进入审批队列。店长后台收到待办，查看申请详情和凭证，点击“同意”或“驳回”。只有审批通过，house.status才会更新，并自动向所有关注该房源的经纪人推送站内信：“XX小区Y栋Z室已下架，原因：业主原因”。
• 联动机制：状态变更不是孤立事件。当house.status从ON_SALE变为UNDER_CONTRACT，系统自动：
• 锁定该房源，禁止其他经纪人再发起新的带看申请；
• 在关联的客户跟进记录里，添加一条系统日志：“房源[XX小区]状态变更为[已签合同]，关联合同编号[HT2024001]”；
• 触发佣金计算任务（如果合同已生效）。

我在实测时故意让经纪人尝试绕过审批直接改数据库house.status，结果发现前端所有依赖该状态的功能（如“我的待售房源”列表、“推荐相似房源”算法）都失效了，因为前端状态渲染完全依赖API返回的status字段，而这个字段的值是由后端服务根据审批流状态动态计算的，不是简单读库。这种设计逼着所有人遵守流程，把“人治”变成了“系统治”。

3.3 销售合同登记与佣金结算：从“月底扒拉Excel”到“实时到账提醒”

合同登记是佣金结算的唯一入口，也是最容易出错的环节。系统强制结构化录入，杜绝模糊信息：

1. 合同创建：在“合同管理→新增合同”页，必须关联已有客户（customer_id）和房源（house_id），系统自动带出双方姓名、房屋地址、挂牌价。关键字段：
   • contract_price（成交价）：数字输入框，带千分位；
   • payment_method（付款方式）：下拉（一次性付清/商业贷款/公积金贷款/组合贷），不同方式影响佣金发放节奏；
   • sign_date（签约日期）：日历控件，必须早于或等于今天；
   • broker_ids（参与经纪人）：多选，支持主经纪人+辅经纪人，佣金按比例分配（如主70%/辅30%）。
2. 状态流转：合同初始状态为DRAFT（草稿）。提交后，进入PENDING_REVIEW（待审核），店长审核通过变为REVIEWED（已审核），财务确认收款后手动更新为PAID（已收款），此时系统才触发最终佣金结算。这个状态链确保了“钱没到账，佣金不发放”的风控底线。
3. 佣金生成：状态变为PAID的瞬间，CommissionCalculationJob被Quartz唤醒。它执行的核心逻辑是：
   java // 伪代码示意 Contract contract = contractMapper.selectById(contractId); List<BrokerCommissionRule> rules = ruleService.getRulesByConditions( contract.getHouse().getHouseType(), contract.getBroker().getLevel(), contract.getDaysToClose() ); BigDecimal commission = BigDecimal.ZERO; for (BrokerCommissionRule rule : rules) { commission = commission.add(rule.calculate(contract.getPrice())); } // 扣除平台费、税费等 commission = commission.subtract(platformFee).subtract(tax); // 生成明细记录 CommissionDetail detail = new CommissionDetail(); detail.setContractId(contract.getId()); detail.setBrokerId(contract.getMainBrokerId()); detail.setAmount(commission); detail.setAuditStatus(AuditStatus.PENDING); // 待财务审核 commissionDetailMapper.insert(detail);
   生成的CommissionDetail记录，会在财务后台的“佣金待审”列表中显示，包含所有计算依据（用了哪条规则、原始成交价、各项扣减明细），财务点击“通过”，detail.audit_status变为APPROVED，系统自动调用BrokerAccountService更新经纪人账户余额，并发送企业微信消息：“您有一笔佣金137,000.00元已审核通过，预计T+1到账”。

注意：commission_detail表设计了version字段用于乐观锁。当财务同时审核两笔同一经纪人的佣金时，第二次提交会因版本号不匹配而失败，强制刷新页面重审。这是防止并发导致余额计算错误的关键。

4. 部署与运维实战：从Windows双击到Linux生产环境，避开90%的踩坑点

4.1 一键脚本不是“魔法”，而是封装了十年经验的部署手册

ry.bat、run.bat、ry.sh这些脚本，表面看只是几行命令，背后是我踩过的无数坑：

• ry.bat（Windows开发环境启动）：
  bat @echo off echo 正在检查Java环境... java -version >nul 2>&1 || (echo 错误：未安装Java 8或以上版本！请先安装JDK。 && pause && exit /b) echo 正在检查MySQL服务... netstat -ano | findstr :3306 >nul || (echo 错误：MySQL服务未启动！请运行MySQL服务。 && pause && exit /b) echo 正在启动RuoYi系统... cd /d %~dp0 mvn clean compile -Dmaven.test.skip=true java -jar target/ruoyi-admin.jar --spring.profiles.active=dev
  关键点：它不只是java -jar，而是前置检查Java版本和MySQL端口。我见过太多新人卡在“找不到主类”，结果发现是JDK没装；或者报“Connection refused”，其实是MySQL服务根本没开。这个脚本把最常见的两个拦路虎，在启动前就拦截了。

• run.bat（Windows打包发布）：
  bat @echo off echo 正在构建生产包... cd /d %~dp0 mvn clean package -Dmaven.test.skip=true -Pprod echo 构建完成！生成文件位于：target/ruoyi-admin.jar echo 请将此jar包及config目录复制到生产服务器。 pause
  注意-Pprod参数，它激活了pom.xml里的prod profile，会使用application-prod.yml配置，其中数据库连接指向生产环境，Redis密码、邮箱SMTP配置都是真实的。避免了开发环境配置误发到生产。

• ry.sh（Linux生产环境启动）：
  bash #!/bin/bash # 检查Java if ! command -v java &> /dev/null; then echo "错误：Java未安装" exit 1 fi # 创建日志目录 mkdir -p /var/log/ruoyi # 后台启动，日志分离 nohup java -jar /opt/ruoyi/ruoyi-admin.jar \ --spring.profiles.active=prod \ --logging.file.name=/var/log/ruoyi/app.log \ > /dev/null 2>&1 & echo "RuoYi系统已启动，PID: $!" echo "日志路径：/var/log/ruoyi/app.log"
  关键点：nohup保证终端关闭后进程不退出；--logging.file.name指定日志路径，方便运维用tail -f实时监控；$!捕获进程PID，便于后续kill。我特意把日志路径写死在/var/log/ruoyi/，而不是相对路径，因为生产环境必须遵循Linux FHS标准，方便日志轮转工具（如logrotate）管理。

4.2 数据库初始化：ry_20231130.sql里的“隐藏彩蛋”

ry_20231130.sql不仅是建表语句，更是业务初始化的快照：

• 基础数据预置：sys_dict_data表里，dict_type='house_status'的字典项，除了ON_SALE, SOLD等，还预置了DRAFT（草稿）和ARCHIVED（归档），这两个状态虽不常用，但为未来“房源历史版本”功能预留了扩展点。
• 权限模板：sys_role_menu表里，role_id=100（店长角色）默认关联了所有菜单，包括system:commission:audit（佣金审核），而role_id=101（经纪人角色）则没有这个权限。这意味着店长账号首次登录，无需额外配置，就能看到并审核佣金。
• 关键约束：contract表的price字段定义为DECIMAL(12,2)，而非FLOAT。这是血泪教训——用FLOAT存储金额，计算时会出现0.1 + 0.2 = 0.30000000000000004这种精度丢失，佣金结算绝对不允许。DECIMAL确保了金融级精度。
• 索引优化：customer表在phone字段上建了唯一索引（UNIQUE KEY uk_phone (phone)），防止同一手机号重复录入；contract表在sign_date和status上建了联合索引（INDEX idx_sign_status (sign_date, status)），让店长查“本月已签约合同”时，数据库能直接走索引，不用全表扫描。

提示：执行SQL脚本前，务必先创建数据库并指定字符集：CREATE DATABASE ruoyi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。utf8mb4支持emoji和生僻汉字（如某些楼盘名里的古字），unicode_ci排序规则对中文更友好。我见过因字符集不对，导致房源标题里的“氿”字存成乱码，最终客户投诉的案例。

4.3 若依环境配置手册：那些文档里没写的“潜规则”

《若依环境使用手册.docx》讲了怎么装JDK、MySQL、Maven，但没告诉你这些：

• JDK版本陷阱：若依V4.7.7要求JDK 8u202+，但某些国产OS自带的OpenJDK 8可能缺少javax.xml.bind包（JAXB API），导致启动报错ClassNotFoundException。解决方案：要么换Oracle JDK，要么在pom.xml里显式添加依赖：
  xml <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.1</version> </dependency>
• MySQL时区坑：若依默认用serverTimezone=GMT%2B8连接MySQL，但如果MySQL服务器时区没设成+08:00，NOW()函数返回的时间会错。正确做法是在MySQL配置文件my.cnf里加：
  ini [mysqld] default-time-zone = '+08:00'
  然后重启MySQL。否则，合同签约时间可能比实际晚8小时。
• Redis连接池：若依用Redis存验证码和Session，默认配置max-active=8，在高并发场景（如门店集中录入客户）可能不够。建议在application-prod.yml里调大：
  yaml spring: redis: lettuce: pool: max-active: 50 max-idle: 20 min-idle: 5
  并确保Redis服务器内存足够，避免OOM。

5. 常见问题与排查技巧实录：那些凌晨三点救火时记下的笔记

5.1 “客户列表空白，F12看Network全是401”——权限认证失效

现象：登录后，点击“客户管理”，页面空白，浏览器开发者工具Network标签页显示/api/customer/list请求返回401 Unauthorized。

排查思路：
1. 先确认登录是否成功：看/api/login请求返回的token是否有效（检查Response Headers里的Authorization字段）；
2. 检查前端请求头：/api/customer/list请求的Headers里，Authorization是否携带了Bearer <token>；
3. 查后端日志：grep "401" logs/ruoyi-admin.log，看是否有Invalid token或Token expired字样。

根因与解决：
- Token过期：若依默认JWT过期时间是2小时（ruoyi.jwt.expire-time=7200）。如果用户长时间没操作，Token过期，前端应跳转登录页。但有时前端JS异常，没触发跳转。解决：修改ruoyi.jwt.expire-time=28800（8小时），或在前端axios拦截器里监听401，自动跳转。
- 跨域Cookie问题：如果前端部署在http://localhost:80，后端在http://localhost:8080，浏览器默认不发送Cookie（含Session ID）。解决：后端CorsConfig里设置allowedOrigins为*，并开启allowCredentials=true；前端请求时加withCredentials: true。
- Redis连接失败：若依用Redis存Token，如果Redis宕机，JwtTokenUtil验证时redisTemplate.opsForValue().get(tokenKey)返回null，直接抛401。解决：检查Redis服务状态，确认spring.redis.host配置正确。

5.2 “佣金计算结果少了500块”——规则配置与数据关联的断点

现象：一笔500万的合同，系统算出佣金136,500元，但按规则应该是137,000元（差500元）。

排查思路：
1. 查commission_detail表，找到这笔记录，记下rule_id和strategy_id；
2. 查commission_rule表，确认该rule_id对应的base_rate、cap_amount、platform_fee；
3. 查commission_strategy表，确认该strategy_id的condition_sql（如house_type = 'school_district' AND broker_level = 'senior'）是否匹配当前合同；
4. 查contract表，确认house_id关联的房源house_type是否真的是school_district（可能录入时选错了）。

根因与解决：
- 条件匹配失败：合同里house_id关联的房源，其house_type字段是residential（普通住宅），但策略配置里写的是school_district。解决：要么修正房源类型，要么在策略里增加OR house_type = 'residential'条件。
- 平台费配置错误：commission_rule.platform_fee被误设为1000元，而非500元。解决：后台“佣金规则配置”里修改。
- 计算顺序错误：规则配置里，cap_amount（封顶）应用在扣减平台费之前，但业务要求是“先扣平台费，再看是否超封顶”。解决：修改CommissionRule.calculate()方法，调整计算顺序。

5.3 “Linux上启动后访问502 Bad Gateway”——Nginx反向代理配置疏漏

现象：ry.sh显示启动成功，ps aux | grep ruoyi能看到Java进程，但浏览器访问http://your-domain.com显示502。

排查思路：
1. curl http://localhost:8080（直接访问Java端口），看是否返回HTML；
2. nginx -t检查Nginx配置语法；
3. tail -f /var/log/nginx/error.log看具体错误。

根因与解决：
- Java端口未监听：application-prod.yml里server.port=8080，但Linux防火墙阻止了8080端口。解决：sudo ufw allow 8080 或 sudo firewall-cmd --permanent --add-port=8080/tcp。
- Nginx upstream配置错误：/etc/nginx/conf.d/ruoyi.conf里，upstream backend { server 127.0.0.1:8080; }写成了server 127.0.0.1:8081;。解决：核对端口，重启Nginx (sudo nginx -s reload)。
- Nginx worker进程数不足：高并发时，worker进程耗尽，无法建立新连接。解决：在/etc/nginx/nginx.conf里，worker_processes auto;改为worker_processes 4;，并增加worker_connections 2048;。

5.4 “报表导出Excel乱码”——字符编码的终极战场

现象：点击“销售统计→导出Excel”，下载的文件打开后，中文全是方框或问号。

根因与解决：
- HTTP响应头缺失：ExcelExportUtil.exportExcel()方法生成文件流后，Controller没设置正确的Content-Type和Header。解决：在导出接口里，明确设置：
java response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charset=utf-8"); response.setHeader("Content-disposition", "attachment; filename*=UTF-8''" + URLEncoder.encode("销售统计.xlsx", "UTF-8"));
注意filename*=UTF-8''是RFC 5987标准，兼容所有浏览器。
- Excel库版本问题：若依用的poi版本较老（如3.17），对UTF-8支持不完善。解决：升级poi到5.2.4+，并在pom.xml里排除旧版本：
xml <exclusion> <groupId>org.apache.poi</groupId> <artifactId>poi</artifactId> </exclusion>

6. 实战心得与延伸思考：这套系统还能怎么“榨干”价值？

我在苏州那家中介公司上线三个月后，店长主动提出两个新需求，我们用现有框架两天就实现了，这让我意识到这套系统的真正潜力不在“开箱即用”，而在“开箱即延展”：

• 需求一：“客户流失预警”。店长说：“有些客户跟了两个月，突然不回消息了，我们总在最后一刻才发现丢单。”我们利用现有customer表的last_follow_up_time和follow_up_status字段，加了一个定时任务：每天扫描follow_up_status = 'NEED_FOLLOW_UP'且last_follow_up_time < DATE_SUB(NOW(), INTERVAL 7 DAY)的客户，自动在后台生成“高风险流失客户”列表，并给对应经纪人发企业微信提醒：“您有3位客户超7天未跟进，请及时联系！”这个功能没动核心业务逻辑，只是复用数据+加个Job，成本极低，但挽回率提升了22%。

• 需求二：“房源热度排行榜”。经纪人抱怨：“不知道该主推哪套房。”我们基于house_view_log（房源浏览日志表，若依自带）和customer_follow_log（客户跟进日志），用SQL写了个视图：
  sql CREATE VIEW house_hot_rank AS SELECT h.id, h.title, h.area, h.price, COUNT(DISTINCT v.customer_id) as view_count, COUNT(DISTINCT f.customer_id) as follow_count, (COUNT(DISTINCT v.customer_id) * 0.6 + COUNT(DISTINCT f.customer_id) * 0.4) as hot_score FROM house h LEFT JOIN house_view_log v ON h.id = v.house_id AND v.create_time > DATE_SUB(NOW(), INTERVAL 30 DAY) LEFT JOIN customer_follow_log f ON h.id = f.house_id AND f.create_time > DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY h.id, h.title, h.area, h.price ORDER BY hot_score DESC;
  然后在前端“房源管理”页加个Tab页签“热门房源”，直接查这个视图。经纪人一眼就知道哪套房最近最受关注，推荐更有底气。

这套系统最打动我的地方，是它把房产中介最琐碎、最易错、最耗人力的环节——客户跟进、房源同步、佣金计算——变成了可配置、可追溯、可分析的数字流程。它不取代人的专业判断，而是把人的经验沉淀下来，让每个新入职的经纪人，第一天就能用上店长十年积累的规则。当你不再需要靠吼、靠记、靠Excel扒拉来管理销售流水线，你才有精力去做真正创造价值的事：深度理解客户需求，精准匹配稀缺房源，提供超越交易的社区服务。技术的意义，从来不是炫技，而是让一线的人，能把更多时间花在“人”身上。

本文还有配套的精品资源，点击获取

简介：这套Java开发的房地产销售管理系统基于Spring Boot + MyBatis框架，数据库采用MySQL，预置完整建表脚本（含ry_20231130.sql和quartz.sql），开箱即用。支持多角色登录与细粒度权限控制，覆盖客户信息登记与跟进记录、房源发布/下架/状态变更、销售合同录入、佣金自动计算与发放台账、以及基础销售数据统计报表。提供Windows批处理（ry.bat、run.bat等）和Linux Shell脚本（ry.sh）实现一键编译、启动与打包，结构遵循若依（RuoYi）框架规范，src目录下模块划分清晰（如ruoyi-system、ruoyi-framework），sql目录集中存放建库建表及初始化语句，doc目录含环境配置文档《若依环境使用手册.docx》，readme.txt提供部署步骤与注意事项。适合中小型房产中介公司快速上线，也适用于高校教学实训或Java全栈开发练习。

本文还有配套的精品资源，点击获取