企业官网建设流程全解析

做房源管理系统这个东西，说实话，市面上能找到的成品大多是单后端架构——要么纯Java要么纯Python，能跑通但扩展性一言难尽。这次我做的这套“基于Java+SSM+Flask的房源管理系统”，采用的是前后端分离加双后端混合架构，把SSM框架和Flask框架放在同一个系统里各干各的活儿，听起来有点怪，但实际用下来相当顺手。

这套系统不是花架子，它能实现房源信息的录入、查询、上下架管理，租客信息的登记与维护，看房预约的流转处理，合同签约到到期提醒的完整闭环，以及管理员后台对全量数据的统计分析。简单说，就是给房产中介、长租公寓运营方或二房东提供的一个可落地的信息化管理工具。如果你是做Java开发的在校生，正愁毕设选题，或者你在中小型租房公司做技术支撑，想找一个能直接改改就用的基础平台，这篇内容可以给你省不少事。

下面我从架构设计到底层实现，再到我实际踩过的坑，完整拆一遍。

1. 项目定位与双后端架构的决策理由

1.1 为什么不用纯SSM，也不用纯Flask

很多人听到“SSM+Flask”第一反应是没必要——SSM本身就能写完整个系统，Flask这种轻量框架塞进来是不是多此一举？当初我也是这么想的，但真正动工前我做了个需求拆解，发现不是炫技，是真的有分工需求。

SSM这套组合在Java生态里的定位非常清晰：Spring管对象生命周期、Spring MVC管路由分发、MyBatis管数据库操作，三者配合做业务系统非常扎实，尤其适合处理复杂的事务逻辑和面向对象的领域建模。房源的增删改查、租客合同的关联查询、签约金额和押金流水这类数据，交给SSM这端，稳定可靠，事务控制也方便。

Flask的价值在哪儿呢？我这边系统里有两个模块不太适合塞进SSM：一个是定时抓取外部房源平台数据的爬虫脚本，一个是给管理端用的轻量数据导出服务。这两个功能用Python写非常快，Flask做HTTP封装也简单，正好互补。最终架构定下来就是：SSM作为主后端负责核心业务管理，Flask作为辅助服务负责数据采集和附加功能，两者共用一个MySQL数据库，通过HTTP接口互调。

这个方案的实战优势还在于部署和迭代的灵活性。如果以后要加推荐算法，Python侧直接用Flask加模块就行，不会动到Java主服务；反过来，管理后台要做复杂的权限体系，直接在Java侧扩展也不会被Python拖累。这种解耦思路，比把一个框架硬撑到所有场景要舒服得多。

1.2 整体功能模块划分

先把系统拆成功能域，方便理解后面的代码。

• 房源管理：录入、编辑、上下架、审核、条件查询、面积价格筛选
• 租客管理：身份信息登记、历史租住记录、黑名单标记、联系记录
• 合同管理：合同创建、押金和租金字段维护、到期提醒、退租归档
• 看房预约：预约提交、经纪人接单、状态流转（待看→已看→已签约→已关闭）
• 权限管理：管理员、经纪人、租客三类角色，Spring MVC拦截器做登录和角色校验
• 数据统计：房源租出率、租金收益走势、区域热度对比，管理后台用ECharts展示
• 辅助服务（Flask端）：房源数据导入接口、到期合同短信提醒，以及Excel报表生成

这些功能叠起来，已经覆盖了一个小型中介公司线上化管理的绝大部分需求。考虑到毕设或项目展示，也能讲出足够多的“技术故事”——双后端、短信通知、定时任务、权限控制，面试官爱听的点基本都涉及了。

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

2.1 建表原则与关系梳理

数据库我用的是MySQL 8.0，建库字符集统一用utf8mb4，千万别用utf8，不然用户填个生僻字或emoji，查询就乱码了。表设计上遵循三范式为主，不追求过度拆分，因为房源系统的核心查询场景很明确：房东/管理员按条件找房源，租客关联合同，合同关联房屋。

前端界面看起来是各种搜索框，真正落到数据库上，就是几条主链路的联合查询。我给表设计定了一条规矩：业务状态都用整型数字标识，比如房源状态0下架、1上架、2待审核、3已租出。字符串状态字段看起来直观，但写SQL条件的时候容易写出隐性bug，比如大小写、全半角空格，万一哪天状态值变了还得写SQL批量替换，数字枚举没有这些破事。

2.2 五张核心表的字段明细

我实际落地了九张表，核心的是下面五张。我直接给建表SQL，你可以直接用，省得自己再敲。

-- 房源信息表 CREATE TABLE `house` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `title` varchar(100) NOT NULL COMMENT '房源标题', `province` varchar(50) DEFAULT NULL COMMENT '省', `city` varchar(50) NOT NULL COMMENT '城市', `district` varchar(50) DEFAULT NULL COMMENT '区县', `address` varchar(255) DEFAULT NULL COMMENT '详细地址', `house_type` varchar(20) DEFAULT NULL COMMENT '户型，如两室一厅', `area` decimal(10,2) DEFAULT NULL COMMENT '面积平米', `price` decimal(10,2) NOT NULL COMMENT '月租金', `status` tinyint DEFAULT '0' COMMENT '0下架 1上架 2待审核 3已租出', `landlord_id` int DEFAULT NULL COMMENT '房东/业主ID', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_city_district` (`city`,`district`), KEY `idx_status_price` (`status`,`price`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源信息表';

房源表是整站的流量入口，查询压力最大。联合索引idx_city_district和idx_status_price是为了让城市+区县筛选、状态+价格排序走上索引，避免全表扫描。我实际测试过，十万条测试数据下，不走索引的模糊查询要600多毫秒，加了合理索引后能压到80毫秒以内，差别非常大。

-- 租客信息表 CREATE TABLE `tenant` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(30) NOT NULL COMMENT '姓名', `phone` varchar(20) NOT NULL COMMENT '手机号', `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号', `occupation` varchar(50) DEFAULT NULL COMMENT '职业', `blacklist` tinyint DEFAULT '0' COMMENT '是否黑名单 0否 1是', `remark` varchar(500) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租客信息表';

租客表核心是手机号唯一索引。这个很重要，一条手机号对应一个自然人，避免同一个租客在系统里被录成多条，导致后续合同关联错乱。

-- 合同表 CREATE TABLE `contract` ( `id` int NOT NULL AUTO_INCREMENT, `house_id` int NOT NULL COMMENT '房源ID', `tenant_id` int NOT NULL COMMENT '租客ID', `rent` decimal(10,2) NOT NULL COMMENT '合同月租', `deposit` decimal(10,2) DEFAULT NULL COMMENT '押金', `start_date` date NOT NULL COMMENT '合同开始日期', `end_date` date NOT NULL COMMENT '合同结束日期', `status` tinyint DEFAULT '0' COMMENT '0履行中 1已到期 2已退租 3已解约', `sign_time` datetime DEFAULT NULL COMMENT '签约时间', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_house_id` (`house_id`), KEY `idx_tenant_id` (`tenant_id`), KEY `idx_end_date` (`end_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='合同表';

合同表的idx_end_date索引是给“到期提醒”用的。系统每隔24小时扫一遍近7天内到期且状态为履行中的合同，凑出list去触发提醒服务。没有这个索引，这个定时任务每次跑都是全表扫描，数据量一上来就很痛苦。

-- 看房预约表 CREATE TABLE `appointment` ( `id` int NOT NULL AUTO_INCREMENT, `house_id` int NOT NULL, `tenant_id` int NOT NULL, `agent_id` int DEFAULT NULL COMMENT '接单经纪人ID', `appoint_time` datetime NOT NULL COMMENT '预约看房时间', `status` tinyint DEFAULT '0' COMMENT '0待接单 1待看房 2已看房 3已签约 4已关闭', `remark` varchar(500) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_agent_status` (`agent_id`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='看房预约表';

-- 管理员表 CREATE TABLE `admin_user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(255) NOT NULL COMMENT 'BCrypt加密存储', `role` tinyint DEFAULT '1' COMMENT '1超级管理员 2经纪人', `real_name` varchar(30) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `status` tinyint DEFAULT '1' COMMENT '1启用 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='后台用户表';

password字段我给的varchar(255)，存储格式是BCrypt的Hash字符串，不是明文密码。项目里Spring Security并不一定都要引入，但BCrypt加密类的引入成本很低，单加一个jbcrypt依赖就能用。明文密码存储这种事情，真的不要再干了，即使只是学习项目，也应该把好习惯养成。

2.3 状态机设计的心得

这套系统里，房源、合同、预约都有状态字段，我强烈建议你在项目里把状态流转画成一张状态机表——不需要会画复杂的图，列个表格就行。比如预约的流转是：待接单→待看房→已看房→已签约，或者待接单→已关闭（租客取消），以及待看房→已关闭（爽约或取消）。在Service层写状态流转update语句时，一律带上“当前状态”条件：

UPDATE appointment SET status = #{newStatus} WHERE id = #{id} AND status = #{currentStatus}

这种写法是乐观锁的思路。如果不带后面那个AND status条件，两个请求同时来，后一个覆盖前一个的更新，状态就可能跳变。比如一个预约明明已经被经纪人接单了，租客取消请求又把状态改成已关闭，再往后经纪人还能把这个已关闭的单子改成已看房，逻辑就乱套了。

3. 双后端落地：SSM主服务与Flask辅助服务实操

3.1 SSM端核心代码结构

SSM端我按标准的Controller-Service-Mapper三层来组织，包结构如下：

com.example.housingsystem ├── controller │ ├── HouseController.java │ ├── TenantController.java │ ├── ContractController.java │ ├── AppointmentController.java │ └── AdminController.java ├── service │ ├── impl │ │ ├── HouseServiceImpl.java │ │ ├── TenantServiceImpl.java │ │ ├── ContractServiceImpl.java │ │ └── AppointmentServiceImpl.java ├── mapper │ ├── HouseMapper.java │ ├── TenantMapper.java │ └── ... ├── entity │ ├── House.java │ ├── Tenant.java │ └── ... ├── common │ ├── Result.java │ ├── PageResult.java │ └── BusinessException.java └── interceptor └── LoginInterceptor.java

Result这个类特别说一下。前后端分离场景，接口统一返回结构是必须的，我用了最简单的泛型包装：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMsg("操作成功"); r.setData(data); return r; } public static <T> Result<T> error(String msg) { Result<T> r = new Result<>(); r.setCode(500); r.setMsg(msg); return r; } }

统一返回结构的好处是前端拿到任何接口的响应，都能用同一套逻辑做拦截和提示，不用一个接口一种格式。这个习惯在做团队项目或接第三方API时特别重要。

Controller层我每个接口都写得很薄，只做参数接收和结果包装，真正的业务判断放在Service层。比如房源上下架，Service层里至少做三件事：确认房源存在、确认当前状态和目标状态之间有合法流转路径、执行update。这些逻辑塞在Controller里也能跑，但代码会越来越胖，最后变成一坨“面条代码”。

3.2 MyBatis映射的几个关键细节

MyBatis这块初学者最容易踩的坑是结果映射。我建议所有实体类的数据库字段映射都用resultMap显式声明，不要靠驼峰自动映射。比如数据库字段是house_type，Java属性是houseType，虽然mybatis-config.xml里开启mapUnderscoreToCoreCase可以自动转换，但多表联查时字段一多就容易“莫名查不到值”，最后定位半天发现是映射问题。显式resultMap虽然啰嗦，但一劳永逸。

分页我用的PageHelper插件，这个工具老但是稳：

PageHelper.startPage(pageNum, pageSize); List<HouseVO> list = houseMapper.selectHouseList(condition); PageInfo<HouseVO> pageInfo = new PageInfo<>(list);

注意PageHelper.startPage后面必须紧跟第一条Mapper查询语句，中间不能有任何其他数据库操作，否则分页会作用到错误的SQL上。这个坑我见过好几个人踩，都是因为startPage之后做了个日志查询或者权限判断，导致分页失效或者数据错乱。

复杂查询我用动态SQL。比如房源列表的条件筛选，户型、面积区间、价格区间、区域、状态都是可选项，用where标签加if判断最合适：

<select id="selectHouseList" resultMap="HouseResultMap"> SELECT * FROM house <where> <if test="city != null and city != ''"> AND city = #{city} </if> <if test="district != null and district != ''"> AND district = #{district} </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> <if test="houseType != null and houseType != ''"> AND house_type = #{houseType} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

这里有个细节：比较运算符大于号小于号在XML里必须转义，用<和>，否则XML解析直接报错。我最早写的时候经常漏，后来习惯写完就全局搜一下有没有裸的“<”。

3.3 Flask端的辅助模块是怎么做的

再来说说Flask端的定位。这一侧我用Python 3.9 + Flask 2.2，主要负责两个轻量服务：房源批量导入的接口和合同到期的短信提醒。

房源批量导入这块，场景是中介手里有一批Excel房源数据，要快速录入系统。人工一条条在后台填太痛苦，我做了一个接口：前端上传Excel，Flask接收后用pandas读取，做数据清洗和校验，再通过HTTP调用Java端的接口批量写入MySQL。流程如下：

from flask import Flask, request, jsonify import pandas as pd import requests app = Flask(__name__) # Java端SSM服务的房源新增接口 JAVA_HOUSE_API = "http://localhost:8080/house/add" @app.route("/api/house/import", methods=["POST"]) def import_house(): file = request.files.get("file") if not file: return jsonify({"code": 500, "msg": "请上传Excel文件"}), 200 df = pd.read_excel(file.stream) required = ["title", "city", "address", "price", "house_type", "area"] missing = [col for col in required if col not in df.columns] if missing: return jsonify({"code": 500, "msg": f"缺少列: {missing}"}), 200 success_count = 0 for _, row in df.iterrows(): payload = { "title": row["title"], "city": row["city"], "address": row["address"], "price": float(row["price"]), "house_type": row["house_type"], "area": float(row["area"]), "status": 1 } resp = requests.post(JAVA_HOUSE_API, json=payload, timeout=5) if resp.status_code == 200: success_count += 1 return jsonify({"code": 200, "msg": f"导入完成，成功{success_count}条"}), 200 if __name__ == "__main__": app.run(port=5000, debug=False)

这里有个设计细节：Python端不直接操作数据库，而是调用Java端的接口写入。为什么？因为Java端有完整的业务校验逻辑，比如价格合法性、必填字段校验、操作日志记录，如果Python绕过Java直接写库，那这部分逻辑就重复实现了一遍，一旦两边逻辑不同步，数据质量就失控了。

再看合同到期提醒。Java端有个定时任务，每24小时扫描快到期合同，把即将到期的合同信息通过HTTP POST发给Flask服务，Flask再对接短信平台发送通知：

@app.route("/api/notify/expiring", methods=["POST"]) def notify_expiring(): data = request.get_json() contracts = data.get("contracts", []) for c in contracts: phone = c["tenant_phone"] house_address = c["house_address"] end_date = c["end_date"] # 这里对接实际的短信平台API，比如阿里云短信 # send_sms(phone, f"您的合同将于{end_date}到期，地址：{house_address}") pass return jsonify({"code": 200, "msg": f"已处理{len(contracts)}条提醒"}), 200

定时任务在Java端用Spring自带的@Scheduled注解，cron表达式每天凌晨两点执行。这种分工的好处是，Java端不用引第三方短信SDK，Python端也不用搞定时任务，两边各管一段，职责非常清爽。

4. 前后端交互与联调的关键细节

4.1 统一登录态与权限校验

前后端分离之后，登录态是一个绕不开的坎。我没有引入复杂的JWT方案，用的是HttpSession加上Spring MVC拦截器。首次登录成功后，把管理员信息放进session里，后续每次请求浏览器自动带上Cookie，拦截器负责校验：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("loginUser"); if (user == null) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录或登录已过期\"}"); return false; } return true; } }

拦截器注册时要注意路径匹配，我这里是拦截所有路径，但放行登录接口和Flask辅助服务回调接口：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/admin/login"/> <mvc:exclude-mapping path="/api/flask/**"/> </mvc:interceptor> </mvc:interceptors>

如果你用的是Spring Boot方式整合SSM，就在配置类里注册WebMvcConfigurer，效果一样的。

这里有个实战细节：前端请求必须带上withCredentials，否则跨域请求不会携带Cookie，登录状态就保不住。我之前调试的时候，后端Session明明有数据，前端就是拿不到登录态，查了半天发现是axios默认不跨域带Cookie。

4.2 跨域问题处理

跨域是前后端分离联调时必现的问题。前端跑在Vue默认的8080端口，后端Java跑在8080，Flask跑在5000，三个端口互相访问，跨域请求满天飞。我是这样解决的：

Java端写一个CorsFilter，统一处理跨域头：

@Component public class CorsFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response = (HttpServletResponse) res; HttpServletRequest request = (HttpServletRequest) req; // 实际项目中这里不要用*，要使用前端的真实地址 response.setHeader("Access-Control-Allow-Origin", "http://localhost:8080"); response.setHeader("Access-Control-Allow-Credentials", "true"); response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS"); response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization"); // 预检请求直接放行，不进入业务逻辑 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { response.setStatus(HttpServletResponse.SC_OK); return; } chain.doFilter(req, res); } }

核心点是Access-Control-Allow-Origin不要用*，因为和Allow-Credentials=true是互斥的，用了浏览器照样拦你。Flask端处理跨域用flask-cors库，两行代码解决：

from flask_cors import CORS CORS(app, supports_credentials=True)

4.3 前端页面集成要点

前端我用的是Vue 2 + Element UI + ECharts。这套组合在管理后台类项目里已经相当成熟，生态好，组件全，遇到问题随便一搜就有答案。

页面规划上，我做了六个核心视图：登录页、数据看板（聚合统计图表）、房源管理（列表+表单弹窗）、租客管理、合同管理、预约管理。数据看板是展示成果的重点，我放了四个核心统计卡片和两个图表——一个展示房源状态分布，一个展示近半年租金收入趋势。这些数据都来自Java端统计接口，一次请求返回聚合数据，前端直接渲染。

@GetMapping("/admin/dashboard") public Result<Map<String, Object>> dashboard() { Map<String, Object> data = new HashMap<>(); // 房源总数、已租出、在租、待审核 data.put("houseTotal", houseService.countHouse()); data.put("houseRented", houseService.countByStatus(3)); data.put("houseActive", houseService.countByStatus(1)); data.put("tenantTotal", tenantService.countTenant()); // 近六个月租金收入 List<Map<String, Object>> trend = contractService.getRentTrendByMonth(6); data.put("rentTrend", trend); return Result.success(data); }

前端图表我用的ECharts，注意一点：ECharts的实例在Vue组件销毁时必须调用dispose销毁，不然组件频繁切换时浏览器的内存会一直涨，页面越来越卡。这个小坑排查起来很隐蔽，但就是细节问题。

5. 实际开发中踩过的坑与排查技巧

5.1 数据库中文乱码问题

这个几乎每个做JavaWeb项目的人都会遇到。表现是：后台录入的中文存进数据库变成问号。排查路径是固定的，从上到下逐个确认：

1. 数据库连接URL必须带useUnicode=true&characterEncoding=utf8两个参数
2. MySQL配置文件my.ini里character-set-server=utf8mb4
3. 建库建表字符集统一utf8mb4
4. 前端提交时确保编码是UTF-8，Content-Type请求头里带上charset=UTF-8

我遇到过一次诡异的情况：数据库连接参数对了，表结构也是utf8mb4，但通过Flask端导入的数据中文还是乱码。最后定位到是pandas读取Excel时，默认的引擎对中文字段处理有问题，需要在read_excel时显式指定dtype=str和encoding相关的参数。所以跨技术栈传数据时，字符编码的问题要在每一层都盯一遍。

5.2 MyBatis的“参数不存在”报错

MyBatis报Parameter 'xxx' not found. Available parameters are [arg1, arg0, param1, param2]这个错，多半是Mapper接口方法穿了多个参数，但没有加@Param注解。Spring Boot 2.x+MyBatis整合后，多参数必须显式加@Param，否则MyBatis无法把参数名和SQL里的#{}对应上。

List<Contract> selectExpiringContracts(@Param("endDate") String endDate, @Param("status") int status);

这个问题在xml里用#{endDate}传参时必现，初学者经常一脸懵。我的经验是：凡是Mapper接口方法参数超过一个，一律加@Param，不要依赖编译参数名保留（那个默认是关的）。

5.3 Flask端口与Spring Boot端口冲突

开发时Java端跑8080，Flask端跑5000，看似不冲突。但如果你本机装了其他服务占用了对应端口，启动就会报Address already in use。排查命令是：

# 查看端口占用情况 lsof -i:8080 lsof -i:5000 # 找到PID后强制结束进程 kill -9 PID

Windows环境用netstat -ano | findstr 8080，然后taskkill /PID xxx /F。这种问题通常不是代码bug，但是会让人一头雾水，尤其是换了台电脑演示项目时。建议写一个启动说明文档，把端口占用检查和改端口方法都列清楚。

5.4 SSM整合时Bean找不到的问题

SSM项目自己搭建框架时经常报NoSuchBeanDefinitionException，一般是三个原因：

一是Spring配置文件和Spring MVC配置文件重复扫描了同一个包，导致Bean被创建了两次，或者扫描路径不匹配。我的习惯是：Spring配置文件扫描service和mapper，Spring MVC配置文件只扫描controller。

二是Mapper接口没有在Spring配置里注册。用XML整合方式要在spring-dao.xml里配置MapperScannerConfigurer：

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.example.housingsystem.mapper"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>

三是Service实现类没有加@Service，或者@Autowired注入时按类型找不到唯一Bean。本地调试时可以临时把报错信息打出来看具体缺哪个类，解决一个是一个。

5.5 Excel导入时的数据类型陷阱

Flask端导入Excel，最容易被坑的是“看起来是数字，其实pandas读出来是科学计数法”或者“身份证号变成浮点数”。比如租客身份证18位，Excel里如果单元格格式是常规，pandas读出来就成了8.88E+17，精度直接丢失。

解决方案是读取时强制转成字符串，并且用astype处理：

df["id_card"] = df["id_card"].astype(str).str.replace(r"\.0$", "", regex=True)

这个replace是去掉字符串末尾的“.0”，因为浮点转字符串会带上小数位。实际操作中最好再加一个判断：if len(id_card) != 18, 这条数据标记为导入失败，不能硬塞进数据库。数据校验宁可严格，不要宽松，否则后面合同关联时会出各种幺蛾子。

6. 项目运行环境与调试文档要点

6.1 环境版本清单

这套系统我用的是以下环境，给你做个参考：

JDK版本我特意选的1.8，不是系统不支持更高版本，而是SSM这套生态在网上能搜到的资料绝大多数基于JDK8，出了问题好排查。你用JDK11+也完全没问题，但没必要在非核心细节上给自己找麻烦。

6.2 调试文档应该写什么

“调试文档”这个交付物是毕设或项目汇报里最常见的附赠材料，很多人不知道写什么，最后两页纸了事。我的建议是至少包含以下四块：

第一部分是环境搭建步骤。JDK、Maven、MySQL、Navicat的安装和配置，每一个都要写清楚版本和下载来源。第二部分是数据库初始化说明。sql脚本的导入方式，以及初始账号密码是什么，我给了两个内置账号：超级管理员admin/admin123，经纪人agent01/123456。第三部分是运行步骤。先启动MySQL，再启动Java端（Tomcat或Spring Boot内嵌容器），再启动Flask端，最后启动Vue前端。四段依次排好，照着做就能跑起来。第四部分是接口文档。核心接口的请求方式、参数、返回结果示例，不用每个都写，覆盖房源增删改查、登录、统计三块就够。

这份文档的价值在于，项目交付后你自己或者接手的人能快速跑起来，而不是在环境配置上卡三天。也建议把这份文档同步到GitHub仓库的README里，演示的时候直接打开给面试官或答辩老师看，专业感一下就上来了。

6.3 初始化数据的准备技巧

系统刚跑起来时，数据库是空的。如果直接打开页面，看板上一片零，列表页一片空白，展示效果大打折扣。建议写一个数据初始化脚本，预置几十条测试数据。房源数据涵盖不同区域、不同户型、不同价格段，租客数据20条左右，合同数据至少有履行中和已到期的各几条，预约数据覆盖不同状态。

为了让数据更逼真，你可以写个Python脚本批量生成测试数据，地址字段用真实的道路名和小区名拼接。有人可能会觉得这是“造假数据”，但这是项目演示的常规操作，目的是展示系统的功能完整性。注意一点：测试数据只在开发环境中使用，交付时要给用户一个干净的初始化脚本，两者分开，否则用户看到的演示数据会干扰他录入自己真实的房源。

7. 项目演示与后续扩展建议

7.1 答辩演示时的操作顺序

如果你拿这套系统做毕业设计答辩或项目展示，操作顺序一定要提前设计好，不要上去瞎点。我的习惯是：

先打开数据看板，让评委一眼看到整体数据。然后演示房源录入——新建一套房源，填各种字段，保存后在列表里能看到并可以上下架操作。接着演示条件查询——按区域和价格区间筛选，展示出列表的结果。再演示预约看房流程——从新建预约，到经纪人接单，到状态变更。最后打开合同模块，演示创建合同和到期提醒效果。

全程大约十五分钟，覆盖系统的核心功能闭环，重点突出双后端各自发挥的作用。这块要能在讲的时候说清楚：Java端负责的是什么，Flask端负责的是什么，为什么要这样拆分。这比单纯念PPT有说服力得多。

7.2 这个项目还能怎么扩展

系统基础功能完整，但想更进一步的话，有几个明确的优化方向。

最推荐的是引入Redis做缓存。现在首页热门的房源列表，每次刷新都会查数据库，加了Redis之后可以把热门房源缓存起来，设置五分钟过期，显著降低数据库压力。Spring Boot整合Redis非常快，而且这个优化在简历上写出来是加分项。

其次是前后端彻底分离。目前我的项目中Vue是独立的前端工程，但Java端仍然通过Tomcat部署，如果换成Spring Boot内置Tomcat，再用Nginx做反向代理，前后端分离的架构会更有说服力。

还有权限控制升级。现在就是简单的登录校验加角色区分，如果做成Spring Security + JWT的方案，把用户的角色和接口权限关联起来，比如经纪人只能操作自己的房源，管理员才能看到全量统计数据，这套系统的业务完整度和技术含金量都会上一个台阶。

最后一个方向是数据可视化增强。当前是把统计结果放在ECharts图表里，后续可以定时生成周报PDF，自动发送给运营人员。Flask端用WeasyPrint或ReportLab可以轻松实现，正好和现有的Flask辅助服务生态衔接上。

我个人做完这套系统最大的感受是：技术选型没有绝对的最好，只有是否匹配场景。SSM加Flask的混合架构虽然看起来不够“纯粹”，但它在实际项目中的确解决了我遇到的问题——复杂业务用Java稳扎稳打，灵活脚本用Python快速实现。这个设计思路本身就是可以迁移到其他项目里的经验。

最后分享一个小技巧：整个项目从开发到调试，建议始终用Git管理，每次完成一个模块就提交一次。不要等到全部写完再统一提交，那样万一某次改崩了，回滚要回滚一大片。我这次项目全程分成三十多次提交，每次commit信息都写清楚改了什么，后期排查问题时按提交记录回看代码演进，效率高很多。能做到这一点，不管系统本身还是你的开发习惯，都已经比大多数同行好一个档次了。