Python房价可视化预测系统：数据清洗、回归训练与Flask部署全解析

简介这是一份基于Python的房价可视化预测系统课程设计资料面向计算机相关专业学生、毕业设计选题者以及需要快速搭建房价评估项目的开发者。资料包含系统说明书Word文档、完整源码和项目截图围绕交通、教育、工作、生活等多维度指标提供可视化分析帮助用户全面评价目标房产的综合价值。压缩包共178个文件大小8.9MB文件类型涵盖后端脚本与配置类文件rb、erb、yml、前端样式与交互脚本scss、js、html、数据库备份文件dump及Docker部署配置既能展示系统目录结构也可直接用于本地环境运行和二次开发。已有2143人浏览学习适合作为课程设计参考、毕设拓展或项目实训素材。借助说明书可以快速理解设计逻辑通过截图能直观核对功能效果源码与配置文件则提供了从基础功能到部署上线的完整闭环。1. 看房评估不能靠感觉Python 房价可视化预测系统到底解决什么问题同一个小区、同样面积的两套房价格为什么能差出十几万通勤时间、学区资源、周边生活配套这些软指标很难靠肉眼统一折算。这套基于 Python 的房价可视化预测系统就是把这些因素拆成交通、教育、工作、生活四个维度用地图、条形图和评分卡把房子周边的真实情况摊开给你看再基于历史成交数据训练回归模型反过来判断一套房的价格合不合理。适合正在找课程设计或毕业设计题目的在校生想练手 Python 数据分析全流程的入门者以及需要快速搭一套 Web 交互产品的开发者。压缩包自带 Word 说明书、完整源码和数据库备份拆开按顺序跑就能看到数据变成评估结论的全过程。2. 先拆资源包文件构成、技术栈与数据流转链路拿到压缩包的第一步不是急着 pip install而是先把文件清单过一遍搞懂每一份文件在整个系统里负责什么角色。这套系统的文件组织方式比一般课程设计规范得多——数据文件、数据库备份、部署脚本、前端模板分开放意味着你不仅能跑通页面还能顺着文件关系理解数据是怎么一步步流到网页上的。2.1 资源包文件清单与职责对照先看最直接的文件构成。压缩包解开后主要文件与它们在系统里的分工如下表我按使用顺序排列文件类型在系统里的职责export.xlsx.axlsxExcel 数据文件房源样本数据包含面积、户型、总价、经纬度等基础字段mydb.dumpSQL 导入文件MySQL 数据库备份含表结构与全部业务数据Dockerfile / .dockerignore构建配置容器化构建脚本用于一键复现运行环境bundle依赖/资源包项目依赖或静态资源的打包集合index.html.erbHTML 模板房源列表首页展示所有房源的基础信息map.html.erbHTML 模板地图可视化页展示房源与周边配套的空间分布bar.html.erbHTML 模板统计对比页用条形图展示各维度聚合结果show.html.erbHTML 模板单套房源详情页集中展示四项评估得分基于python的房价可视化预测系统 说明书.docxWord 文档课程设计说明书含需求分析、设计说明、功能截图这套布局里最值得注意的细节是 export.xlsx.axlsx 这个文件名它不是两个文件而是同一个 Excel 数据文件。.axlsx 是 Excel 开放 XML 格式的标准扩展名Windows 上双击一般也能直接用 Excel 打开。另外模板统一以 .html.erb 结尾写惯了纯 .html 的同学可能觉得奇怪实际渲染逻辑是由 Flask 的 Jinja2 模板引擎负责的页面文件名只要和 render_template 里的字符串精确匹配就行后缀叫什么都不影响运行。真正决定系统能不能跑起来的是数据库备份和源代码之间的依赖关系——mydb.dump 里存的表结构必须和代码里 SQL 查询的字段名一致这个点在后文部署部分会重点展开。2.2 技术栈推断与选型理由从文件类型和功能描述看整套系统的技术栈是课程设计里最典型的 Python Web 组合Flask 做 Web 框架pandas 做数据处理scikit-learn 训练房价预测模型MySQL 做数据存储前端用 ECharts 渲染地图和条形图Docker 负责统一运行环境。为什么是 Flask 而不是 Django我在跑过几轮课程设计之后越来越笃定这套系统的核心不是内容管理而是把查数据库、算特征、画图表这一串动作串起来。Flask 的路由和视图函数一一对应单文件就能启动对第一次接触 Web 项目的学生来说心智负担小得多。Django 当然更完整但 app 划分、admin 后台、中间件这些机制对交付一个可视化系统来说是额外负担。如果评审老师问选型理由一句话就能答清楚Flask 足够覆盖本项目全部需求且代码量更少、调试路径更短。数据层面选 pandas 没有悬念。Excel 数据读进来后要做字段清洗、按行政区聚合、和多表做关联pandas 的 DataFrame 操作比纯 SQL 写起来直观尤其在调试阶段能快速 print 出来看中间结果。sklearn 负责模型部分LinearRegression 和 RandomForestRegressor 都是开箱即用不需要额外装深度学习框架对课程设计场景是最稳的选择。2.3 数据从 Excel 到页面的完整流转整个系统的数据流可以概括成一条直线原始 Excel → MySQL 数据库 → Flask 后端查询 → JSON 聚合 → 模板渲染 → 浏览器展示。排错的时候也是沿着这条链路从前往后查定位到哪一段断了就处理哪一段。第一步是把数据库恢复到本地。mydb.dump 是 mysqldump 导出的 SQL 文件直接用命令行导入# 先建库再导入备份指定 utf8mb4 避免中文乱码 mysql -u root -p -e CREATE DATABASE IF NOT EXISTS house_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -u root -p house_db mydb.dump第一条命令显式指定 utf8mb4 字符集第二条把 dump 数据导入刚建好的库。如果直接拿现成的空库导入目标库字符集默认如果是 latin1后面页面里所有中文房源信息全会变成问号。导入完成后顺手查一下数据是否正常——SELECT 一条带中文的记录确认没问题再启动服务能省掉后面一大半关于编码的排查时间。第二步是让 Flask 能连上数据库。常见做法是用 SQLAlchemy 建一个引擎再交给 pandas 直接查询# app/db.py 数据库连接与查询 from sqlalchemy import create_engine import pandas as pd # 连接参数按实际环境修改用户名:密码主机:端口/库名 engine create_engine( mysqlpymysql://root:123456127.0.0.1:3306/house_db?charsetutf8mb4 ) def load_houses(): # 查询房源主表字段名以数据库实际表结构为准 sql SELECT id, title, area, total_price, lon, lat FROM house_info df pd.read_sql(sql, engine) return df这里 charsetutf8mb4 是驱动与数据库交互时的编码参数必须和建库时保持一致pymysql 是 Python 连 MySQL 的驱动环境里没装的话需要先 pip install pymysql。load_houses() 返回 DataFrame后续的聚合计算都基于它完成。为什么不用 Excel 直读因为 MySQL 里除了房源主表通常还有配套的周边 POI 表、地铁站点表多表 join 在数据库里做比在 pandas 里做更清晰而且 mydb.dump 把结构都定义好了直接恢复到库就是完整的一套。第三步是 Flask 路由把聚合结果交给模板地图页的简化逻辑如下# app/app.py 地图片路由 from flask import Flask, render_template import pandas as pd app Flask(__name__) app.route(/map) def map_page(): # 从数据库加载房源按行政区聚合出均价 df load_houses() agg df.groupby(district)[total_price].mean().round(2) data {district: list(agg.index), avg_price: list(agg.values)} # data 传给模板由前端地图组件直接消费 return render_template(map.html.erb, datadata)这段逻辑的关键是后端不把几百条明细全部塞给前端而是先聚合出行政区均价再打包成 JSON。地图组件拿到 district 和 avg_price 两个数组渲染一张按区域着色的价格分布图浏览器端压力小页面加载快。如果直接把明细数据全量传给前端做聚合数据量一旦上千页面会明显卡顿这是课程设计里最常见的性能翻车点。到这里数据流的骨架就清楚了。后续每一章节的可视化和预测都是在这条链路上插入不同的处理逻辑。3. 评估可视化四维度交通、教育、工作、生活怎么量化摘要里说的从交通、教育、工作、生活等方面评估一套房子落到代码上其实就是两类动作算距离和数数量。前者解决离地铁站几分钟的问题后者解决周边有多少超市医院的问题。两类结果再叠加房价数据就是一套多维度的可视化评估卡片。3.1 交通维度用 Haversine 公式算站点可达性交通维度是所有评分项里计算量最大的。项目里一般存有地铁站、公交站的经纬度表要算的是每个房源与最近站点的球面距离。这里不能直接套用平面上两点间距离公式因为经纬度坐标对应的是球面直接算欧氏距离在维度越高的地区误差越大。# app/features.py 计算两经纬度点之间的球面距离公里 from math import radians, sin, cos, asin, sqrt def haversine(lon1, lat1, lon2, lat2): # 输入为十进制度数返回公里数 R 6371.0 # 地球平均半径单位公里 lon1, lat1, lon2, lat2 map(radians, [lon1, lat1, lon2, lat2]) dlon lon2 - lon1 dlat lat2 - lat1 a sin(dlat/2)**2 cos(lat1) * cos(lat2) * sin(dlon/2)**2 return 2 * R * asin(sqrt(a)) # 对每一套房取最近一站的距离作为交通得分依据 def nearest_station_distance(house_lon, house_lat, stations_df): dists stations_df.apply( lambda st: haversine(house_lon, house_lat, st[lon], st[lat]), axis1 ) return dists.min()参数上需要留意两点R6371.0 是地球平均半径单位是公里想改成英里就换 3958.8stations_df 里的经度lon在前、纬度lat在后这个顺序最容易写反一旦写反所有距离计算结果全部错误且难以察觉。haversine 公式在 3 公里以内的精度足够房源配套统计使用如果数据量大到几十万条建议改用 geopy 库的 geodesic 接口性能更好且边界处理更稳。交通评分不一定只看原始距离更合理的做法是把距离折算成步行时间距离除以步行速度 4.8km/h得到分钟数超过 20 分钟的站点权重直接记 0。这样说明书里能写清楚步行 15 分钟可达地铁站而不是距离 1.2 公里评审听起来更直观。3.2 教育维度学校覆盖率与等级加权教育维度在课程设计里通常抽象成两步圈定半径统计学校数量。学生家长更关心小区对口哪个学校但详细划片信息在一般数据集里拿不到退而求其次的做法是统计周边学校分布并按等级加权。# app/features.py 教育维度聚合逻辑 from math import log1p EDU_RADIUS_KM 2.0 # 周边学校统计半径 WEIGHT {primary: 1.0, middle: 0.8, high: 0.6} # 学校等级权重 def education_score(house, schools_df): # 筛选半径内的学校 schools_df[dist] schools_df.apply( lambda s: haversine(house[lon], house[lat], s[lon], s[lat]), axis1 ) nearby schools_df[schools_df[dist] EDU_RADIUS_KM] if nearby.empty: return 0 # 按类型加权求和后取对数控制分数涨幅 weighted (nearby[type].map(WEIGHT) * nearby.get(rating, 1)).sum() return round(log1p(weighted), 2)EDU_RADIUS_KM 直接决定评分的区分度城区房源密集半径从 2 公里收到 1.5 公里分数立刻拉开差距如果数据集本身学校稀疏我会把半径放到 2.5 公里否则大部分房源教育分都是 0可视化地图上一片冷色没法看。log1p 的目的是压缩极大值——某套房子周边有 30 所学校而另一套只有 5 所直接用线性数量会让后者分数趋近于 0取对数后差距控制在合理范围页面评分卡看起来更平衡。map.html.erb 模板会把学校点渲染成散点图层用户拖拽地图时能直观看到房源几公里内的学校分布。这和纯表格展示的最大区别在于地图上位置关系一目了然东侧 600 米有小学比一个数字有说服力得多。3.3 工作维度通勤时间折算与就业中心距离工作维度考量的核心通勤成本。课程设计通常不接入高德或百度地图的通勤 API常见做法是源数据里记录主要就业中心或商务区坐标计算房源到中心的距离再按经验速度折算成通勤时间。# app/features.py 通勤时间估算 TRANSIT_SPEED_KMH 25 # 公共交通平均速度含等车经验值 DRIVE_SPEED_KMH 30 # 驾车高峰均速经验值 def commute_time(house, office_centers_df): # 取最近就业中心返回驾车与公交两种通勤分钟数 nearest office_centers_df.apply( lambda c: haversine(house[lon], house[lat], c[lon], c[lat]), axis1 ).min() drive_min round(nearest / DRIVE_SPEED_KMH * 60, 1) transit_min round(nearest / TRANSIT_SPEED_KMH * 60, 1) return {drive_min: drive_min, transit_min: transit_min}25 和 30 这两个速度常数是经验值城市公交含等车和堵车均速 25km/h 已经算乐观高峰驾车算上红绿灯30km/h 也是偏高的估计。这两个数不是官方发布值所以我在项目里一直把它们提取成配置项集中在文件头部定义后文做敏感性分析时也方便。通勤时间的作用是横向比较——A 房和 B 房哪个上班更近而不是精确预报某天早晨几点能到公司这个边界要在说明书里写清楚。提示答辩时如果老师追问速度参数依据能准确说出取自城市平均速度经验值可在配置文件中调整比含糊解释更有说服力。3.4 生活配套维度条形图与详情页的聚合展示生活配套是四个维度里最容易讲清楚的把超市、医院、银行、公园、商场等 POI 按类别统计数量用条形图和评分卡展示。bar.html.erb 渲染的正是这套聚合结果show.html.erb 则负责单套房子的综合评估展示。# app/app.py 生活配套统计路由 app.route(/bar) def bar_page(): df load_houses() # 每套房统计 1km 范围内的 POI 数量 df[poi_count] df[house_id].apply(lambda hid: count_nearby_pois(hid, 1.0)) # 按小区分组求平均排序后交给条形图 summary df.groupby(compound)[poi_count].mean().sort_values(ascendingFalse) return render_template(bar.html.erb, summarysummary)条形图页的核心价值在于横向比较把多个小区的配套数量放进同一张图哪边生活便利度高一目了然。show.html.erb 则是单套房评估报告页把交通、教育、工作、生活四个维度得分做成四格卡片外加与城市均价的对比条。这张页面是写说明书时最实用的素材——直接截图放进系统实现章节可视化评估的论点就立住了。四个维度算完后会统一做归一化把原始分映射到 0100再按权重生成总评分。权重通常写成交通 0.3、教育 0.3、工作 0.2、生活 0.2页面里也可以做成滑块让用户自己调属于可选的交互增强功能。整个可视化层到这里闭环地图看分布、条形图看对比、详情页看结论。4. 预测模型部分特征工程、回归训练与参数调整可视化解决这套房周边好不好预测解决这套房价格合不合理。两个模块互为佐证可视化提供环境和配套的体感预测模型用历史成交数据告诉你同类房源的市场价区间。课程设计里模型不需要多先进但整个流程必须完整——从特征构造、训练评估到持久化部署。4.1 特征工程从房源字段到模型输入进入模型前第一步是把原始字段变成模型能直接吃的数值特征。export.xlsx 里的房源数据如果按常见结构看大致包含面积、户型、楼层、总楼层、建造年份、朝向、所在区域等字段。原始字段不能直接喂给 sklearn需要做如下处理# train/build_features.py 特征构造 def build_features(df, reference_year2024): features pd.DataFrame() # 面积直接用连续值 features[area] df[area] # 建造年份转成房龄避免模型把年份当绝对值学习 features[age] reference_year - df[build_year] # 楼层占比5楼在6层住宅是次顶在32层高层完全不算高层 features[floor_ratio] df[floor] / df[total_floor] # 朝向做 one-hot注意先统一大小写 features[orient_north] (df[orientation].str.lower() north).astype(int) features[orient_south] (df[orientation].str.lower() south).astype(int) # 行政区做类别编码序号不表示远近 features[district_id] df[district].astype(category).cat.codes # 外部特征周边配套数与最近站点距离 features[poi_count] df[house_id].apply(lambda x: count_nearby_pois(x, 1.0)) features[nearest_station_km] df[house_id].apply(lambda x: nearest_station_km(x)) return features这段代码有三个细节值得单独说明。第一楼层要转成 floor_ratio 占比而不是直接用 floor 值原因此前说过——楼层数在不同楼高的建筑里语义不同。第二朝向 one-hot 前加 str.lower() 是为了防止数据源里 North 和 north 两种写法被当成两个特征细小的数据不一致会直接稀释模型精度。第三district_id 用 .cat.codes 得到的只是分类序号比如西湖区编码 0、拱墅区编码 1区与区之间没有数值大小含义模型只把它当类别型特征使用。reference_year 这个参数值得单独提如果不抽象成参数代码里写死 2024到了明年再用就得改代码。更麻烦的是训练脚本和预测接口如果各写一份特征构造函数年份一旦不一致模型输出的偏差会非常隐蔽。我现在的习惯是把它做成公共模块训练和预测共用一个函数。4.2 基线模型线性回归与训练集划分课程设计里第一个能跑的模型通常是线性回归。它快速、可解释能作为后续换模型的精度基线。用 sklearn 的 train_test_split 和 LinearRegression 即可完成# train/train_model.py 线性回归训练与评估 from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error, r2_score X build_features(df) y df[total_price] # 预测目标为总价单位万元 # 8:2 划分训练集与测试集固定随机种子保证可复现 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 ) model LinearRegression() model.fit(X_train, y_train) y_pred model.predict(X_test) print(fMAE: {mean_absolute_error(y_test, y_pred):.1f}万元) print(fR2: {r2_score(y_test, y_pred):.4f})random_state42 的作用是固定随机划分结果让你每次运行输出一致——复盘实验和跟老师复现结果都不会出现上次 R² 0.85 这次 0.79的尴尬。这个数字本身没有任何数学意义纯粹是习惯约定。MAE 的解读很直接平均每套房预测价与实际成交价差几万块课程设计里做到 815 万量级就算及格说明模型框架搭对了。第一次跑如果发现 R² 是负数不要急着换模型先检查特征里是不是混入了泄漏变量——比如把挂牌价本身当成特征加入训练R² 会虚高到 0.99 甚至 1.0但这样的模型没有预测意义因为推理时根本拿不到未来的挂牌价。这个坑我在带学生项目时见过不止一次。注意random_state 只影响数据划分不是模型调参参数不要把它放进 GridSearchCV 的 param_grid 里放进去了也不会提升精度。4.3 提升精度的常规手段随机森林与网格搜索线性回归抓不住房价与面积、区位的非线性关系因此多数课程设计最终会换成随机森林。随机森林不对特征做标准化对异常值容忍度高是性价比最高的升级方案# train/train_model.py 随机森林网格搜索 from sklearn.ensemble import RandomForestRegressor from sklearn.model_selection import GridSearchCV param_grid { n_estimators: [100, 200], # 子树数量 max_depth: [10, 15, 20], # 最大深度 min_samples_leaf: [2, 4] # 叶节点最少样本数 } model RandomForestRegressor(random_state42) grid GridSearchCV(model, param_grid, cv5, scoringr2, n_jobs-1) grid.fit(X_train, y_train) print(fbest params: {grid.best_params_}) print(fbest CV R2: {grid.best_score_:.4f})GridSearchCV 里的 n_jobs-1 表示用满所有 CPU 核心数据量几千条时秒级出结果如果数据量上到十万级建议减少候选参数组合或者换成 HistGradientBoostingRegressor否则搜索时间会拖到现场演示等不住。cv5 表示五折交叉验证最终成绩比单次划分更可信。随机森林在房价预测场景下的 R² 通常能到 0.850.92 区间对课程设计已经完全拿得出手。训练完成后一定要持久化模型否则每次重启 Flask 都重新训练一次既不现实也没必要# 保存训练好的模型到 model 目录 import joblib joblib.dump(grid.best_estimator_, model/house_price.pkl)加载侧只需要 model joblib.load(model/house_price.pkl)一次加载反复使用。把这个 pkl 文件放进项目的 model 目录启动系统时就不用再等训练流程跑完预测接口直接消费模型文件即可。5. 部署与运行避坑数据库导入、Docker 启动、模板路径的五个坑位系统本身不复杂但能跑和能顺利跑之间隔着好几个常见坑。这些坑在课程设计答辩和自测时最容易翻车我按踩过的顺序列出来每条给出排查路径。坑位一mydb.dump 导入后中文乱码现象导入 dump 后页面房源标题和小区名称全部显示成问号或者乱码。原因mysqldump 备份文件本身是 utf8 编码但目标数据库默认字符集不是 utf8mb4。导入时 MySQL 按目标库的默认字符集解析插入中文字符就被截断或替换掉了。解决导入前先显式建库指定字符集导入后立刻验证mysql -u root -p house_db -e SELECT title FROM house_info LIMIT 5;能正常输出中文再启动服务。如果还是乱码检查 Flask 连接串里是否少了 charsetutf8mb4。这个问题两分钟就能验证但一旦漏掉后面所有页面排查都会白费功夫。坑位二pip 安装依赖超时或编译失败现象执行 pip install -r requirements.txt 时某个包卡住十几秒后超时或者某个依赖在编译阶段报错退出。原因默认 PyPI 源在国外网络波动时容易超时部分包需要编译原生扩展本机缺少编译工具链也会直接失败。解决换国内镜像源并指定超时时间pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple --timeout 60如果 requirements.txt 本身缺失或版本不全根据项目 import 顺序逐个安装核心包顺序一般是 Flask、pandas、numpy、scikit-learn、PyMySQL、SQLAlchemy。装一个测一个不要一次性装完再排查否则报错了根本不知道是哪个包引起的。坑位三Docker 启动后浏览器访问不到页面现象镜像构建成功docker run 执行成功但访问宿主机端口一直转圈或拒绝连接。原因Flask 默认监听 127.0.0.1这是容器内部的回环地址宿主机访问不到另一个常见原因是端口映射写错。解决Flask 入口处把监听地址显式改成 0.0.0.0# app.py 入口0.0.0.0 表示接受容器外部请求 if __name__ __main__: app.run(host0.0.0.0, port8000, debugFalse)Docker 运行后检查 docker ps 看端口映射是否形如 0.0.0.0:8000-8000/tcp再 docker logs 看有没有 * Running on 0.0.0.0:8000 的监听日志。监听正常还连不上基本就是容器里的 MySQL 连接配置不对去 Flask 启动日志里找数据库连接报错。坑位四模板加载报错 jinja2.exceptions.TemplateNotFound现象访问路由时直接抛 TemplateNotFound但 .html.erb 文件明明就在 templates 目录里。原因Flask 默认在项目根目录下的 templates 目录里查找模板目录名必须叫 templates 而不是 template另外 .erb 后缀不是 Flask 默认的 .htmlrender_template 传文件名时必须精确匹配大小写也不能错。解决先确认目录结构find . -name *.erb -o -name *.html | head -20对照实际路径修改 render_template 里的字符串。如果模板在子目录里比如 detail/show.html.erb就写 render_template(detail/show.html.erb)。坑位五预测结果恒定为一条直线现象调用预测接口几百条记录预测出来的价格全部相同或都接近训练集均值。原因模型在训练阶段就崩了通常是特征矩阵里有大量缺失值或重复值导致决策树全部落到同一个叶节点另一个可能是目标列选错把某个常量字段当成了 y。解决训练前先跑 df.isna().sum() 统计缺失数值列用中位数填充类别列用众数填充再做 df.nunique() 检查目标字段取值个数如果只有 1 个模型当然只会输出常量。这两条检查是数据体检的基本项每次都该跑一遍。6. 把课程设计升级成预测接口Flask API 封装与单点校验可视化系统跑通后推荐做一件进阶的事把页面上才能看到的预测能力封装成 HTTP 接口。好处有两个——脱离网页也能验证模型效果后续接入小程序或外部工具时直接调接口不需要改任何业务代码。封装思路很清晰在 Flask 里新增一个 POST 路由接收 JSON 格式的房源特征加载模型文件返回预测总价和参考区间。# app/api/predict.py 预测接口 from flask import Blueprint, request, jsonify import joblib, pandas as pd bp Blueprint(pred_api, __name__) model joblib.load(model/house_price.pkl) # 启动时加载一次 bp.route(/api/predict, methods[POST]) def predict(): body request.get_json() # 按训练时的特征顺序构造行数据顺序错了模型输出直接偏移 row pd.DataFrame([{ area: body[area], age: 2024 - body[build_year], floor_ratio: body[floor] / body[total_floor], poi_count: body[poi_count], nearest_station_km: body[nearest_station_km] }]) pred model.predict(row)[0] # 返回预测价与按训练误差折算的建议下界 return jsonify({ predicted_price_wan: round(float(pred), 2), suggested_low: round(float(pred - 10), 2) })接口写好之后用 curl 做一次最小验证curl -X POST http://127.0.0.1:8000/api/predict \ -H Content-Type: application/json \ -d {area:89,build_year:2015,floor:12,total_floor:18,poi_count:25,nearest_station_km:0.6}返回的 predicted_price_wan 可以直接和 export.xlsx 里同面积同区域的实际成交价对照差值落在训练 MAE 两倍以内说明模型加载和特征构造都没问题。我自己动手做这类接口时吃过一次教训训练脚本里特征顺序是 area、age、floor_ratio接口里图省事写成了 age、area、floor_ratio模型不报错但预测结果偏得离谱排查了半小时才发现是列顺序变了。从那以后我每次接预测服务都强制先用一条已知样本做单点校验——传进去一个带真实成交价的样本看接口输出和实际价的差距是否合理验证通过再继续接业务。希望帮到你。本文还有配套的精品资源点击获取