先说一个总的判断二手房价格分析预测系统这个题目是近年来大数据类毕业设计里“性价比”最高的一档。为什么这么说因为它兼顾了三样东西一是技术栈完整前端、后端、数据库、算法模型、可视化全都沾答辩时有东西可讲二是业务逻辑清晰房价预测是个人人都有感知的场景评委不需要你解释“你这个系统解决什么问题”三是可扩展性强往上可以加爬虫、加地图可视化、加时间序列分析改成平台型项目也毫不违和。我经手过的类似项目有十几个大部分同学从零开始到最后顺利答辩周期大概在六到八周。这篇就把选型思路、数据预处理、算法实现、系统集成、调试排错一条线全部讲透。你要做的不只是跑通一个Demo而是搞清楚每一层为什么这么做。1. 这个毕设题目到底在考察什么很多同学拿到题目第一反应是“房价预测”——然后就开始找算法。这个顺序其实反了。毕设题目到了答辩环节评委首先看的是你“有没有完整的工程思维”其次才是算法新颖度。1.1 题目的三层技术栈拆解表面上看这是一个“基于Django的二手房价格分析预测系统”但实际考察的是三层能力第一层是数据层你要有足够量的二手房数据并且数据是干净可用、字段完备的。这里会自然涉及数据采集爬虫或官方数据集、数据清洗去重、缺失值处理、异常值剔除、数据存储MySQL建库建表。第二层是算法层价格预测不是凭空喊价而是基于特征面积、户型、楼层、朝向、装修、区域位置等建立回归模型。考察点是特征工程是否合理、模型选择是否有依据、评估指标是否说清楚了R2、RMSE、MAE都是必问项。第三层是应用层Django负责把数据和模型包成一个可交互的Web系统用户能查询房价、筛选条件、看到预测结果和可视化图表。这一层考察的是MVC架构理解、ORM熟练度、前端页面整合能力。如果你只做了其中一层——比如只写了个算法脚本就打完收工——那答辩基本会被追问到失语。三层都得有缺一不可。1.2 为什么选二手房而不是新房新房价格受预售限价、开发商定价策略影响数据上“失真”明显二手房是买卖双方真实博弈的结果更加市场化也更适合做统计建模和价格预测。从数据特征上看二手房字段丰富单价、总价、面积、户型、朝向、楼层、建筑年代、区域板块、环线位置等做特征工程时有料可挖。用大白话说新房价格像官方指导价二手房价格像市场价。你拿市场价做预测评委更有共鸣你也更好解释业务场景。1.3 什么基础的同学适合选这个题会Python基础语法、有过Django或Flask入门经验有简单的SQL操作能力愿意花时间学pandas做数据清洗、用scikit-learn跑模型前端部分不需要你写出多惊艳的页面Bootstrap或简单的HTMLCSSECharts就够了。如果以上条件满足两条以上这个题目在你的可控范围内。如果你是纯零基础建议先花两周补一下Python核心语法和Django基础然后再开题。2. 技术选型和系统架构的底层逻辑选型这件事很多同学是“看哪篇博客火就抄哪个”这是最坑的。技术栈之间不是简单的“能不能用”的关系而是“是不是最合理”的关系。2.1 Django为什么比Flask更合适同样是Python Web框架Flask确实轻量但对毕设这种需要完整后台管理的项目来说它太“裸”了。Django自带Admin后台、ORM、表单处理、认证系统、迁移机制你在开发二手房系统时要写的大量“管理端逻辑”可以省掉一半工作量。举一个具体的例子Django的Admin后台可以直接注册房源模型然后你就能在后台增删改查房屋数据。如果没有Admin你得自己写一整套CRUD页面这个工作量对于一个毕设来说是实打实的负担。另一个关键点是Django的ORM。MySQL的数据表操作可以直接用Python对象的方式完成迁移流程也标准化了。你改一下模型字段执行python manage.py makemigrations和migrate就同步到数据库不容易出现手写SQL时字段不一致的问题。对于基础不算强的同学这一条能少踩很多坑。2.2 MySQL数据存储的细节考量MySQL是这个项目的默认数据库选型也是配套文档里最常见的组合。建库的时候建议直接用utf8mb4字符集避免存入中文或特殊字符时出现乱码或索引长度溢出。数据表设计上我建议最少要有这几张表house_info房源信息主表标题、小区名、区域、板块、总价、单价、面积、户型、楼层、朝向、装修、建筑年代、经度纬度等house_prediction预测记录表保存用户预测请求和对应结果user用户表如果实现登录注册region_price_stats区域均价统计表可以用于页面展示图表表之间的关联不要太复杂毕设阶段用外键关联到小区或区域维度就够了过度设计反而让你在写ORM查询时绕来绕去。2.3 前后端交互与整体模块划分系统整体分为三个端用户端负责房源检索、价格预测输入、预测结果展示、数据可视化图表查看管理端负责房源数据维护、模型管理、预测日志查看算法模块独立成一个服务模块不直接写在视图函数里而是单独封装成模型训练、数据处理、预测三个子模块。推荐的做法在Django项目中单独建一个app叫analysis或者叫predict专门放数据处理和模型相关代码。这样一来Django视图代码和算法代码解耦调试时方便打印中间结果答辩时也可以清晰地给评委展示“模型集成点在哪”。数据流大概是这个链路MySQL原始房源数据 → pandas读取并预处理 → 生成特征矩阵 → 训练回归模型并保存为pkl文件 → Django视图加载模型文件 → 接收前端传入的房屋特征 → 返回预测价格。3. 数据是整套系统的地基说实话毕设项目里一半的翻车现场不是算法跑不起来而是数据根本没法用。要么是字段缺失太严重要么是数据量太小——几百条二手房记录去做机器学习模型的泛化能力基本是空谈。3.1 数据从哪里来三种路径的取舍方案第一种是写爬虫去房产平台采集。这个方案展示度最高因为答辩的时候你可以说“我实现了爬虫模块”但要承担反爬机制带来的不确定性还不排除数据合规层面的争议。建议如果有原始数据积累比如课程设计阶段已经抓过可以拿来直接用临时去爬的话要评估时间和风险。第二种是使用公开的数据集。国内外都有公开的房价数据资源国内一些高校的数据共享平台也能找到脱敏后的二手房成交数据。这个方案最省时间但是数据质量和字段完整性要自己做一遍盘查模型解释时不能露出“数据来源说不清楚”的破绽。第三种是半模拟数据结合小样本真实数据。拿一批真实的二手房数据作为基础再通过合理的规则扩充样本量。比如已知某个小区的真实成交单价可以按照楼层差、朝向差、装修差生成合理范围内的模拟房源。这个方案适合数据量不够但想要完整流程的现状但讲究一个度——模拟数据比例不能太高否则模型结论的客观性会被质疑。我个人的倾向建议优先找到一份字段完整的历史二手房数据集一般几千条起步来源写清楚是“经过脱敏处理的历史挂牌数据”这在毕设场景下既安全又够用。3.2 数据清洗的六个关键步骤数据拿到手之后千万不要直接丢进模型。我整理一份标准的清洗流水线去重同一房源在不同时间点被重复抓取是常态。按照小区名、面积、户型、朝向这几个字段做联合去重保留最新一条记录。缺失值处理分两种。数值型字段面积、总价缺失占比超过30%的建议直接删除该条少量缺失可以用均值或中位数填充。类别型字段朝向、装修用众数填充。异常值剔除单价异常低的远低于区域均价、总价异常高的、面积异常的比如1平米或者5000平米都要剔除。可以用IQR四分位距法也可以结合业务常识手动设阈值。单位统一面积统一为平方米总价统一为万元单价统一为元/平方米。文本字段标准化朝向字段有“南”“朝南”“正南”等写法要先做映射统一否则特征编码时会产生一堆稀疏列。经纬度和区域字段补全如果数据集里没有经纬度也要保证至少有“区域板块”字段用于后续的可视化和特征归并。清洗完成后你可以顺手写一份Excel报告输出一个数据质量统计表答辩时展示“数据清洗前后对比”这是一个非常加分的亮点。3.3 特征工程才是预测效果的胜负手很多同学在预测房价时只用了面积和总价两个字段这等于把“预测房价”做成了“单价乘以面积”评委一眼就能看穿。真正有效的特征工程是从原始字段中挖掘出对价格有解释力的信息。举几个实用的例子单价与总价的分离模型训练时用单价作为目标值预测时再结合面积反推总价比直接预测总价更稳定。楼龄特征建筑年代这个字段单独用没有“感觉”但把它转换成“房子到现在多少年”就是独立的有效特征。旧房子折旧明显模型更容易学到趋势。楼层区间把楼层从“具体数字”归为“低层、中层、高层、顶底层”。不同楼层的溢价逻辑不同比如中间楼层通常最受欢迎这个归约比单纯用数字直连更能表达业务规律。面积区间分段面积特征和价格不完全是线性关系。可以把面积按区间分段或者同时保留面积和面积平方让模型自己去拟合非线性。区域房价编码统计每个区域的房源均价然后把这个区域均价作为该区域所有房源的一个新特征。这样模型直接感知到“同一面积的两套房在不同区域的价差”比让模型自己从几十个区域哑变量里学省力得多。这些特征不一定全部用上但如果你能在代码里表现出“我做了特征工程”答辩时已经和那些只调用fit函数的人拉开一个档次。4. 价格预测模型的选择与实现算法部分要清醒一点这不是算法创新类论文所以目标不是发明新模型而是用一种或两种主流的回归模型把预测任务做扎实。能用、可解释、有对比就已经是很标准的毕设模型章节。4.1 几种常见模型的对比线性回归最基础的回归模型优点是可解释性强回归系数直接体现特征对房价的影响方向和幅度。缺点是线性假设在很多真实场景下过于粗糙预测精度有限。决策树回归不需要特征缩放能捕捉非线性关系但单棵树很容易过拟合泛化能力一般。随机森林回归基于多棵决策树的集成模型抗过拟合能力强对异常值也相对鲁棒。在二手房数据上通常比线性回归有明显提升。缺点是解释性较差不过可以用特征重要性曲线来做一定弥补。XGBoost梯度提升树的一种实现精度往往是最高的那一档但调参相对复杂跑起来的资源开销也更大。如果你的数据量不是特别大随机森林和XGBoost的差距不会特别夸张。我的建议是回归方案用随机森林作为主模型线性回归作为对照。在答辩时可以给出两个模型的评估对比表说明为什么最终选择了随机森林——因为R2更高、RMSE更小并且它对特征数值范围不敏感省去了大量标准化工作。如果你的项目文档需要体现“进阶”再补充XGBoost的结果。4.2 核心训练代码骨架模型训练部分我给出一个可直接参考的代码骨架它包含数据读取、数据集切分、训练、评估、模型保存全流程import pandas as pd import joblib from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import r2_score, mean_absolute_error, mean_squared_error # 读取清洗后的数据 df pd.read_csv(clean_house_data.csv) # 特征列与目标列 feature_cols [area, bedrooms, living_rooms, bathrooms, floor_level, building_age, region_code, decoration_code, unit_price_region] X df[feature_cols] y df[unit_price] # 目标为单价 # 切分训练集和测试集随机种子固定保证可复现 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42) # 随机森林回归 model RandomForestRegressor( n_estimators300, max_depth20, min_samples_split5, min_samples_leaf2, random_state42 ) model.fit(X_train, y_train) # 预测与评估 y_pred model.predict(X_test) r2 r2_score(y_test, y_pred) mae mean_absolute_error(y_test, y_pred) rmse mean_squared_error(y_test, y_pred, squaredFalse) print(fR2: {r2:.4f}, MAE: {mae:.4f}, RMSE: {rmse:.4f}) # 特征重要性输出 importance_df pd.DataFrame({ feature: feature_cols, importance: model.feature_importances_ }).sort_values(importance, ascendingFalse) print(importance_df) # 保存模型后续给Django调用 joblib.dump(model, house_price_model.pkl)4.3 两个容易翻车的细节第一个细节是目标值的选择。我强烈建议你预测单价而不是总价。因为总价 单价 × 面积而面积本身已经作为特征输入了模型去拟合总价的时候会放大面积的作用反而削弱其他特征的影响力。直接预测单价然后页面再展示预估总价单价 × 面积业务逻辑更自然模型也更稳健。第二个细节是类别特征一定要编码。像朝向、装修、楼层区间、区域这些文本字段不能直接塞进模型。最简单的方式是用LabelEncoder转成数值编码。如果类别之间没有天然顺序比如区域编码可以用OneHotEncoder不过这样特征维度会升高样本量不够的话建议还是LabelEncoder加特征重要性筛选。from sklearn.preprocessing import LabelEncoder for col in [floor_level, region_code, decoration_code]: le LabelEncoder() df[col] le.fit_transform(df[col]) joblib.dump(le, flabel_{col}.pkl)5. 系统功能落地与Django集成模型训好了接下来就是把模型“塞进”Web系统里。这一部分是大多数同学最生疏的地方——算法能跑但不知道怎么让用户在网页上完成一次预测。5.1 数据可视化模块怎么设计可视化是一个能显著提升系统“高级感”的模块。推荐三类图表第一类是区域均价柱状图/折线图展示各个区域的挂牌均价对比用户能直观看到哪些区域房价高、哪些低。第二类是房价分布直方图包括总价分布和单价分布让用户理解整体数据的集中趋势。第三类是面积与价格的关系散点图也可以按区域着色展示不同区域中面积和价格的相关模式。工具就用ECharts它是纯前端的JavaScript图表库。Django后端只需要把统计数据通过JsonResponse传给模板前端接收后渲染ECharts配置即可。这里有个常见坑ECharts直接让后端传字典数据前端取数据时类型对不上要确保decimal和numpy类型先转为标准的float/int。import json from django.http import JsonResponse def region_price_stats(request): query SELECT region, AVG(unit_price) as avg_price, COUNT(*) as cnt FROM house_info GROUP BY region result cursor.execute(query).fetchall() data [{region: row[0], avg_price: round(float(row[1]), 2), count: row[2]} for row in result] return JsonResponse(data, safeFalse)5.2 Django视图层与模型的集成方式在Django里集成训练好的sklearn模型核心就是加载pkl模型文件并封装一个预测函数。视角上看无非是用户提交表单视图函数接收参数预处理后调用模型预测再返回结果。一个常见的设计模式是在项目下建一个utils或者model_utils.py文件专门放模型加载与预测逻辑视图函数只负责请求分发。import joblib import numpy as np model joblib.load(ml_models/house_price_model.pkl) label_encoders { floor_level: joblib.load(ml_models/label_floor_level.pkl), region_code: joblib.load(ml_models/label_region_code.pkl), decoration_code: joblib.load(ml_models/label_decoration_code.pkl) } def predict_unit_price(feature_dict): floor_level label_encoders[floor_level].transform([feature_dict[floor_level]])[0] region_code label_encoders[region_code].transform([feature_dict[region_code]])[0] decoration_code label_encoders[decoration_code].transform([feature_dict[decoration_code]])[0] features np.array([ feature_dict[area], feature_dict[bedrooms], feature_dict[living_rooms], feature_dict[bathrooms], floor_level, feature_dict[building_age], region_code, decoration_code, feature_dict[region_price] ]).reshape(1, -1) predicted_unit_price model.predict(features)[0] return predicted_unit_price注意预测时仍然要做和训练时一样的编码逻辑否则单个新数据进来会报“类别代码不存在”或者“特征数量不匹配”的错误。5.3 房源管理模块与后台设计房源管理模块以Django Admin为主会省力很多。你在admin.py里注册模型然后配置list_display和list_filterfrom django.contrib import admin from .models import HouseInfo admin.register(HouseInfo) class HouseInfoAdmin(admin.ModelAdmin): list_display (title, region, area, total_price, unit_price, building_age) list_filter (region, decoration, floor_level) search_fields (title, region, community)这样你就拥有了一个可以直接录入、编辑、删除房源数据的后台不用再手写一套管理页面。答辩时直接打开Admin后台给评委展示“我这个系统具备完整的数据管理能力”非常直观。但要注意Admin是默认的管理界面如果你想要更个性化的管理端比如只看部分字段、按条件批量修改可以用Django的表单和视图来补充毕设阶段做一个可用的管理页就足够。6. 数据库设计与查询优化的实践经验这一章单独拎出来讲因为数据库是很多同学的短板挂着MySQL的名头实际只会做一个单表查询。6.1 核心表结构参考以house_info表为例一个相对规范的表结构大概是这样字段名类型说明idint primary key auto_increment主键communityvarchar(100)小区名称regionvarchar(50)所在区域boardvarchar(50)板块total_pricedecimal(12,2)总价万元unit_pricedecimal(10,2)单价元/平方米areadecimal(10,2)面积平方米bedroomstinyint卧室数living_roomstinyint客厅数bathroomstinyint卫生间数floor_levelvarchar(20)楼层区间decorationvarchar(20)装修情况building_ageint楼龄年longitudedecimal(10,6)经度latitudedecimal(10,6)纬度created_atdatetime default current_timestamp入库时间用Django的模型类定义时注意decimal字段要指定max_digits和decimal_placesclass HouseInfo(models.Model): community models.CharField(max_length100) region models.CharField(max_length50) board models.CharField(max_length50) total_price models.DecimalField(max_digits12, decimal_places2) unit_price models.DecimalField(max_digits10, decimal_places2) area models.DecimalField(max_digits10, decimal_places2) bedrooms models.SmallIntegerField() living_rooms models.SmallIntegerField() bathrooms models.SmallIntegerField() floor_level models.CharField(max_length20) decoration models.CharField(max_length20) building_age models.SmallIntegerField() longitude models.DecimalField(max_digits10, decimal_places6, nullTrue, blankTrue) latitude models.DecimalField(max_digits10, decimal_places6, nullTrue, blankTrue) created_at models.DateTimeField(auto_now_addTrue)6.2 查询性能调优数据量不大的时候Django默认的ORM查询没问题但不要为了偷懒写所有数据一次性load到内存再过滤。比如区域均价统计错误写法list(HouseInfo.objects.all())然后在Python内存里循环累加正确写法用annotate配合聚合函数让MySQL帮你去重和计算。from django.db.models import Avg, Count region_stats ( HouseInfo.objects .values(region) .annotate(avg_priceAvg(unit_price), cntCount(id)) .order_by(-avg_price) )还有一点如果查询频繁按region筛选给region字段加个索引db_indexTrue价格排序的话给unit_price加索引。索引不是越多越好但这两个常见的过滤排序字段加了基本没副作用。6.3 MySQL连接配置与中文乱码Django连接MySQL时在settings.py里需要配置好字符集。用PyMySQL的话添加一行DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: house_price_db, USER: root, PASSWORD: yourpassword, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, }, } }然后记得在mysql连接时补一句init_command或者在MySQL建库时指定CREATE DATABASE house_price_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;乱码问题绝大多数是数据库建错了字符集或者连接串没带charset造成的。项目启动后先往库里手动插一条中文数据测试能正常显示再继续往下开发。7. 毕设答辩高频问题与调试避坑手册这里整理的是我长期观察下来毕设答辩现场最容易“爆”的问题每一个背后都有活生生的翻车案例。7.1 答辩评委最爱问的十个问题1. 你的数据是从哪里来的这是第一大高频问题所有人都被问过。回答思路说清楚原始数据来源、数据量大小、采集方式、清洗过程。如果数据是半模拟的也要坦诚说明规则生成的逻辑和合理性这反而显得你严谨。2. 数据量这么小比如只有几千条你凭什么认为模型预测结果可信回答思路强调模型评估指标例如R2在0.8以上说明在测试集上表现稳定同时自曝训练集的局限提出未来可通过扩大样本量提升模型泛化能力。这种回答既真诚又不失专业。3. 为什么选随机森林不选线性回归回答思路给出对比实验表格说明随机森林在R2、RMSE上优于线性回归并且对异常值和特征尺度更鲁棒。关键是让评委知道你做过了比较而不是只会用默认参数。4. 你的模型是怎么从Django里被调用的回答思路讲清楚“训练时保存模型文件运行Web服务时加载模型文件输入特征经过同样的编码转换后送入模型输出结果返回页面”这条链路。现场可以演示一次预测过程。5. 特征重要性是怎么算的有什么意义回答思路说明随机森林自带基于杂质减少的特征重要性评估并解释哪些特征对房价影响最大通常面积、区域、楼龄排前三结合业务面分析合理性。6. 如果用户输入的数据和训练集分布差异很大模型会怎样回答思路承认模型会有局限可以增加“预测置信度”提示或“输入范围限制”来规避异常输入但本质问题是训练数据覆盖度不足这是数据驱动模型共有的困难。7. 系统有哪些扩展点回答思路可以提未来接入房价时间序列、引入地理位置的POI数据、接入实时爬虫管道、用深度学习模型做图像估值等。扩展点要合理不要漫无边际吹牛。8. 你做了哪些安全性措施回答思路Django自带的CSRF防护、ORM参数化查询防SQL注入、后台管理需要登录、限制用户输入长度等都是可以讲的点。9. 为什么做Web系统而不直接做一个离线脚本回答思路强调“系统”意味着可视化、可交互、多用户视角这也是毕设题目要求“设计与实现”的本意所在。10. 预测结果可视化是用什么做的回答思路用ECharts做的后端只负责提供数据前端渲染图表。思路清晰的话还可以顺手讲一句“图表组件都做了自适应的响应式布局”。7.2 开发和调试中的七大常见坑坑1数据导入时报“Unknown column”原因CSV里的列名和Django模型字段名对不上。解决先打印CSV的表头和模型字段逐个对照创建一个字段映射字典而不是靠猜。坑2模型预测时维度不匹配原因训练时候的特征顺序和预测时候构造的特征顺序不一致。解决写一个get_feature_vector函数严格按训练时的feature_cols顺序构造数组每次改动特征列表时同步更新这个函数。坑3LabelEncoder训练完、预测时遇到没见过的类别比如测试集里没有某个区域但用户输入了这个区域。解决用encoder.classes_检查类别覆盖范围预测时先判断是否在已有类别中不在的话归入“其他”类别。坑4ECharts图表不显示90%的原因是div容器没有设置高度或者初始化图表的JS代码在DOM加载之前执行。解决给图表容器一个显式的height比如600px并且把初始化代码放在window.onload或者$(document).ready里。坑5Django找不到模板文件原因settings里没有配置DIRS或者模板文件没有放在正确的应用目录下。解决在settings.py中确认TEMPLATES [ { BACKEND: django.template.backends.django.DjangoTemplates, DIRS: [BASE_DIR / templates], APP_DIRS: True, ... } ]坑6ORM查询时N1次数据库查询比如循环中调用关联表查询。解决使用select_related或prefetch_related优化或者直接values()拿到聚合结果。坑7页面预测按钮转圈但后台没有报错也不返回结果这类问题通常在视图函数内部抛了异常但Django对非Debug模式返回了500页面或空白。解决开发阶段把settings里的DEBUG设置成True让错误页显示具体堆栈再不行就在视图的第一行加日志print逐段排查哪一步断了。7.3 代码讲解类的演示技巧答辩展示项目时代码讲解环节很容易变成“照着PPT念代码”。我见过讲得好的同学都是按这个顺序讲的先打开项目目录结构讲清每个模块的作用让评委形成全局认知然后打开模型训练的脚本快速展示数据读取到模型保存的流程重点讲一句“这里我做了一个特征转换是为了让类别特征能被模型识别”再打开Django视图函数演示一次完整的预测请求配合页面运行展示最后打开数据可视化页面点不同的图表说清楚每个图在设计时想表达什么结论。整个过程不要超过六到八分钟剩下的时间留给评委提问。评委问问题时能答上来的就简洁回答答不上来的不要瞎编诚实地说“这块我在开发中还没有深入考虑后续可以做进一步扩展”比硬撑着好得多。8. 文档和配套材料的准备策略毕设文档的重要性不亚于代码本身。评委花在文档上的时间比看代码的时间多得多。文档写得乱、图表缺失、协议不清楚代码再漂亮都会被扣分。8.1 论文或设计文档的章节建议一套标准的结构可以按这个框架走引言与背景说明房价分析的现实意义引入“传统估价方法效率低、主观性强”的问题点相关技术综述简要介绍Django框架、MySQL、回归模型、数据可视化技术需求分析分为功能需求和非功能需求功能需求条目化列清楚系统设计给出架构图、功能模块图、数据库ER图、接口设计系统实现按数据采集、数据处理、模型构建、系统功能四块每块配核心代码和运行截图系统测试功能测试用例表加上预测模型的评估指标表总结与展望客观总结系统完成内容提出不足和改进方向。8.2 技术文档的三个加分点写清楚实验环境版本。Python 3.10、Django 4.2、MySQL 8.0、scikit-learn 1.3等版本号写清楚别人复现时不容易踩兼容坑。画一张数据E-R图。毕设文档里数据库设计的篇幅要足够。用表格列出每张表的字段、类型、约束、说明再画一张简单的实体关系图这部分是评委快速判断你项目“有没有含金量”的快捷方式。做一个预测误差对比表。在模型章节里放一张这样的表模型R2MAERMSE结论线性回归0.722340.53128.7精度一般随机森林0.861570.22210.3精度较优XGBoost0.881435.62078.9略优于随机森林但训练耗时更长然后给一句“综合考虑预测精度和可解释性本项目最终选择随机森林作为核心预测模型”这就是完整的选型逻辑。我看到太多文档写得像流水账全是功能罗列没有设计思路。要把每一处关键设计都解释清楚——为什么字段这么设计、为什么选这个模型这才是“设计与实现”的真正内涵。9. 最后的几点个人体会跟这个题目打交道这么久我最大的感受是二手房价预测系统这个题目本身不难但它是一个很好的“能力放大器”。你用心打磨数据、老老实实做特征工程、把系统每一层梳理通那么在答辩现场你的底气和那些只把代码跑通就完事的同学是完全不同的——因为你对每一个环节都知道“为什么”。如果时间紧张优先顺序应该是数据清洗 模型可用性 可视化图表 管理端功能 额外扩展功能。先把主干做扎实再考虑花活。这个小项目未来能延伸的方向也很明确把静态回归模型换成对时间序列的训练加入房源挂牌时长和带看次数这类过程数据或者爬取周边基础设施的热点数据做特征扩展。已经有一个可用的底子在后续对接真实的业务场景会顺畅得多。最后再分享一个实际管用的小技巧开发期间把每个版本的模型文件和评估指标都留个备份备注好“第几版、用了哪些特征、R2是多少”。我见过很多同学调参调着调着就忘了哪个效果最好有记录的话答辩时可以直接讲“我尝试了多次调优最终保留了一组最优参数”——这句话的含金量评委一听就懂。 
长河君 · 2026/10/15 21:45:38 · 阅读 1.2k 二手房价格预测系统如何设计？从Django到随机森林的完整实战
先说一个总的判断二手房价格分析预测系统这个题目是近年来大数据类毕业设计里“性价比”最高的一档。为什么这么说因为它兼顾了三样东西一是技术栈完整前端、后端、数据库、算法模型、可视化全都沾答辩时有东西可讲二是业务逻辑清晰房价预测是个人人都有感知的场景评委不需要你解释“你这个系统解决什么问题”三是可扩展性强往上可以加爬虫、加地图可视化、加时间序列分析改成平台型项目也毫不违和。我经手过的类似项目有十几个大部分同学从零开始到最后顺利答辩周期大概在六到八周。这篇就把选型思路、数据预处理、算法实现、系统集成、调试排错一条线全部讲透。你要做的不只是跑通一个Demo而是搞清楚每一层为什么这么做。1. 这个毕设题目到底在考察什么很多同学拿到题目第一反应是“房价预测”——然后就开始找算法。这个顺序其实反了。毕设题目到了答辩环节评委首先看的是你“有没有完整的工程思维”其次才是算法新颖度。1.1 题目的三层技术栈拆解表面上看这是一个“基于Django的二手房价格分析预测系统”但实际考察的是三层能力第一层是数据层你要有足够量的二手房数据并且数据是干净可用、字段完备的。这里会自然涉及数据采集爬虫或官方数据集、数据清洗去重、缺失值处理、异常值剔除、数据存储MySQL建库建表。第二层是算法层价格预测不是凭空喊价而是基于特征面积、户型、楼层、朝向、装修、区域位置等建立回归模型。考察点是特征工程是否合理、模型选择是否有依据、评估指标是否说清楚了R2、RMSE、MAE都是必问项。第三层是应用层Django负责把数据和模型包成一个可交互的Web系统用户能查询房价、筛选条件、看到预测结果和可视化图表。这一层考察的是MVC架构理解、ORM熟练度、前端页面整合能力。如果你只做了其中一层——比如只写了个算法脚本就打完收工——那答辩基本会被追问到失语。三层都得有缺一不可。1.2 为什么选二手房而不是新房新房价格受预售限价、开发商定价策略影响数据上“失真”明显二手房是买卖双方真实博弈的结果更加市场化也更适合做统计建模和价格预测。从数据特征上看二手房字段丰富单价、总价、面积、户型、朝向、楼层、建筑年代、区域板块、环线位置等做特征工程时有料可挖。用大白话说新房价格像官方指导价二手房价格像市场价。你拿市场价做预测评委更有共鸣你也更好解释业务场景。1.3 什么基础的同学适合选这个题会Python基础语法、有过Django或Flask入门经验有简单的SQL操作能力愿意花时间学pandas做数据清洗、用scikit-learn跑模型前端部分不需要你写出多惊艳的页面Bootstrap或简单的HTMLCSSECharts就够了。如果以上条件满足两条以上这个题目在你的可控范围内。如果你是纯零基础建议先花两周补一下Python核心语法和Django基础然后再开题。2. 技术选型和系统架构的底层逻辑选型这件事很多同学是“看哪篇博客火就抄哪个”这是最坑的。技术栈之间不是简单的“能不能用”的关系而是“是不是最合理”的关系。2.1 Django为什么比Flask更合适同样是Python Web框架Flask确实轻量但对毕设这种需要完整后台管理的项目来说它太“裸”了。Django自带Admin后台、ORM、表单处理、认证系统、迁移机制你在开发二手房系统时要写的大量“管理端逻辑”可以省掉一半工作量。举一个具体的例子Django的Admin后台可以直接注册房源模型然后你就能在后台增删改查房屋数据。如果没有Admin你得自己写一整套CRUD页面这个工作量对于一个毕设来说是实打实的负担。另一个关键点是Django的ORM。MySQL的数据表操作可以直接用Python对象的方式完成迁移流程也标准化了。你改一下模型字段执行python manage.py makemigrations和migrate就同步到数据库不容易出现手写SQL时字段不一致的问题。对于基础不算强的同学这一条能少踩很多坑。2.2 MySQL数据存储的细节考量MySQL是这个项目的默认数据库选型也是配套文档里最常见的组合。建库的时候建议直接用utf8mb4字符集避免存入中文或特殊字符时出现乱码或索引长度溢出。数据表设计上我建议最少要有这几张表house_info房源信息主表标题、小区名、区域、板块、总价、单价、面积、户型、楼层、朝向、装修、建筑年代、经度纬度等house_prediction预测记录表保存用户预测请求和对应结果user用户表如果实现登录注册region_price_stats区域均价统计表可以用于页面展示图表表之间的关联不要太复杂毕设阶段用外键关联到小区或区域维度就够了过度设计反而让你在写ORM查询时绕来绕去。2.3 前后端交互与整体模块划分系统整体分为三个端用户端负责房源检索、价格预测输入、预测结果展示、数据可视化图表查看管理端负责房源数据维护、模型管理、预测日志查看算法模块独立成一个服务模块不直接写在视图函数里而是单独封装成模型训练、数据处理、预测三个子模块。推荐的做法在Django项目中单独建一个app叫analysis或者叫predict专门放数据处理和模型相关代码。这样一来Django视图代码和算法代码解耦调试时方便打印中间结果答辩时也可以清晰地给评委展示“模型集成点在哪”。数据流大概是这个链路MySQL原始房源数据 → pandas读取并预处理 → 生成特征矩阵 → 训练回归模型并保存为pkl文件 → Django视图加载模型文件 → 接收前端传入的房屋特征 → 返回预测价格。3. 数据是整套系统的地基说实话毕设项目里一半的翻车现场不是算法跑不起来而是数据根本没法用。要么是字段缺失太严重要么是数据量太小——几百条二手房记录去做机器学习模型的泛化能力基本是空谈。3.1 数据从哪里来三种路径的取舍方案第一种是写爬虫去房产平台采集。这个方案展示度最高因为答辩的时候你可以说“我实现了爬虫模块”但要承担反爬机制带来的不确定性还不排除数据合规层面的争议。建议如果有原始数据积累比如课程设计阶段已经抓过可以拿来直接用临时去爬的话要评估时间和风险。第二种是使用公开的数据集。国内外都有公开的房价数据资源国内一些高校的数据共享平台也能找到脱敏后的二手房成交数据。这个方案最省时间但是数据质量和字段完整性要自己做一遍盘查模型解释时不能露出“数据来源说不清楚”的破绽。第三种是半模拟数据结合小样本真实数据。拿一批真实的二手房数据作为基础再通过合理的规则扩充样本量。比如已知某个小区的真实成交单价可以按照楼层差、朝向差、装修差生成合理范围内的模拟房源。这个方案适合数据量不够但想要完整流程的现状但讲究一个度——模拟数据比例不能太高否则模型结论的客观性会被质疑。我个人的倾向建议优先找到一份字段完整的历史二手房数据集一般几千条起步来源写清楚是“经过脱敏处理的历史挂牌数据”这在毕设场景下既安全又够用。3.2 数据清洗的六个关键步骤数据拿到手之后千万不要直接丢进模型。我整理一份标准的清洗流水线去重同一房源在不同时间点被重复抓取是常态。按照小区名、面积、户型、朝向这几个字段做联合去重保留最新一条记录。缺失值处理分两种。数值型字段面积、总价缺失占比超过30%的建议直接删除该条少量缺失可以用均值或中位数填充。类别型字段朝向、装修用众数填充。异常值剔除单价异常低的远低于区域均价、总价异常高的、面积异常的比如1平米或者5000平米都要剔除。可以用IQR四分位距法也可以结合业务常识手动设阈值。单位统一面积统一为平方米总价统一为万元单价统一为元/平方米。文本字段标准化朝向字段有“南”“朝南”“正南”等写法要先做映射统一否则特征编码时会产生一堆稀疏列。经纬度和区域字段补全如果数据集里没有经纬度也要保证至少有“区域板块”字段用于后续的可视化和特征归并。清洗完成后你可以顺手写一份Excel报告输出一个数据质量统计表答辩时展示“数据清洗前后对比”这是一个非常加分的亮点。3.3 特征工程才是预测效果的胜负手很多同学在预测房价时只用了面积和总价两个字段这等于把“预测房价”做成了“单价乘以面积”评委一眼就能看穿。真正有效的特征工程是从原始字段中挖掘出对价格有解释力的信息。举几个实用的例子单价与总价的分离模型训练时用单价作为目标值预测时再结合面积反推总价比直接预测总价更稳定。楼龄特征建筑年代这个字段单独用没有“感觉”但把它转换成“房子到现在多少年”就是独立的有效特征。旧房子折旧明显模型更容易学到趋势。楼层区间把楼层从“具体数字”归为“低层、中层、高层、顶底层”。不同楼层的溢价逻辑不同比如中间楼层通常最受欢迎这个归约比单纯用数字直连更能表达业务规律。面积区间分段面积特征和价格不完全是线性关系。可以把面积按区间分段或者同时保留面积和面积平方让模型自己去拟合非线性。区域房价编码统计每个区域的房源均价然后把这个区域均价作为该区域所有房源的一个新特征。这样模型直接感知到“同一面积的两套房在不同区域的价差”比让模型自己从几十个区域哑变量里学省力得多。这些特征不一定全部用上但如果你能在代码里表现出“我做了特征工程”答辩时已经和那些只调用fit函数的人拉开一个档次。4. 价格预测模型的选择与实现算法部分要清醒一点这不是算法创新类论文所以目标不是发明新模型而是用一种或两种主流的回归模型把预测任务做扎实。能用、可解释、有对比就已经是很标准的毕设模型章节。4.1 几种常见模型的对比线性回归最基础的回归模型优点是可解释性强回归系数直接体现特征对房价的影响方向和幅度。缺点是线性假设在很多真实场景下过于粗糙预测精度有限。决策树回归不需要特征缩放能捕捉非线性关系但单棵树很容易过拟合泛化能力一般。随机森林回归基于多棵决策树的集成模型抗过拟合能力强对异常值也相对鲁棒。在二手房数据上通常比线性回归有明显提升。缺点是解释性较差不过可以用特征重要性曲线来做一定弥补。XGBoost梯度提升树的一种实现精度往往是最高的那一档但调参相对复杂跑起来的资源开销也更大。如果你的数据量不是特别大随机森林和XGBoost的差距不会特别夸张。我的建议是回归方案用随机森林作为主模型线性回归作为对照。在答辩时可以给出两个模型的评估对比表说明为什么最终选择了随机森林——因为R2更高、RMSE更小并且它对特征数值范围不敏感省去了大量标准化工作。如果你的项目文档需要体现“进阶”再补充XGBoost的结果。4.2 核心训练代码骨架模型训练部分我给出一个可直接参考的代码骨架它包含数据读取、数据集切分、训练、评估、模型保存全流程import pandas as pd import joblib from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import r2_score, mean_absolute_error, mean_squared_error # 读取清洗后的数据 df pd.read_csv(clean_house_data.csv) # 特征列与目标列 feature_cols [area, bedrooms, living_rooms, bathrooms, floor_level, building_age, region_code, decoration_code, unit_price_region] X df[feature_cols] y df[unit_price] # 目标为单价 # 切分训练集和测试集随机种子固定保证可复现 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42) # 随机森林回归 model RandomForestRegressor( n_estimators300, max_depth20, min_samples_split5, min_samples_leaf2, random_state42 ) model.fit(X_train, y_train) # 预测与评估 y_pred model.predict(X_test) r2 r2_score(y_test, y_pred) mae mean_absolute_error(y_test, y_pred) rmse mean_squared_error(y_test, y_pred, squaredFalse) print(fR2: {r2:.4f}, MAE: {mae:.4f}, RMSE: {rmse:.4f}) # 特征重要性输出 importance_df pd.DataFrame({ feature: feature_cols, importance: model.feature_importances_ }).sort_values(importance, ascendingFalse) print(importance_df) # 保存模型后续给Django调用 joblib.dump(model, house_price_model.pkl)4.3 两个容易翻车的细节第一个细节是目标值的选择。我强烈建议你预测单价而不是总价。因为总价 单价 × 面积而面积本身已经作为特征输入了模型去拟合总价的时候会放大面积的作用反而削弱其他特征的影响力。直接预测单价然后页面再展示预估总价单价 × 面积业务逻辑更自然模型也更稳健。第二个细节是类别特征一定要编码。像朝向、装修、楼层区间、区域这些文本字段不能直接塞进模型。最简单的方式是用LabelEncoder转成数值编码。如果类别之间没有天然顺序比如区域编码可以用OneHotEncoder不过这样特征维度会升高样本量不够的话建议还是LabelEncoder加特征重要性筛选。from sklearn.preprocessing import LabelEncoder for col in [floor_level, region_code, decoration_code]: le LabelEncoder() df[col] le.fit_transform(df[col]) joblib.dump(le, flabel_{col}.pkl)5. 系统功能落地与Django集成模型训好了接下来就是把模型“塞进”Web系统里。这一部分是大多数同学最生疏的地方——算法能跑但不知道怎么让用户在网页上完成一次预测。5.1 数据可视化模块怎么设计可视化是一个能显著提升系统“高级感”的模块。推荐三类图表第一类是区域均价柱状图/折线图展示各个区域的挂牌均价对比用户能直观看到哪些区域房价高、哪些低。第二类是房价分布直方图包括总价分布和单价分布让用户理解整体数据的集中趋势。第三类是面积与价格的关系散点图也可以按区域着色展示不同区域中面积和价格的相关模式。工具就用ECharts它是纯前端的JavaScript图表库。Django后端只需要把统计数据通过JsonResponse传给模板前端接收后渲染ECharts配置即可。这里有个常见坑ECharts直接让后端传字典数据前端取数据时类型对不上要确保decimal和numpy类型先转为标准的float/int。import json from django.http import JsonResponse def region_price_stats(request): query SELECT region, AVG(unit_price) as avg_price, COUNT(*) as cnt FROM house_info GROUP BY region result cursor.execute(query).fetchall() data [{region: row[0], avg_price: round(float(row[1]), 2), count: row[2]} for row in result] return JsonResponse(data, safeFalse)5.2 Django视图层与模型的集成方式在Django里集成训练好的sklearn模型核心就是加载pkl模型文件并封装一个预测函数。视角上看无非是用户提交表单视图函数接收参数预处理后调用模型预测再返回结果。一个常见的设计模式是在项目下建一个utils或者model_utils.py文件专门放模型加载与预测逻辑视图函数只负责请求分发。import joblib import numpy as np model joblib.load(ml_models/house_price_model.pkl) label_encoders { floor_level: joblib.load(ml_models/label_floor_level.pkl), region_code: joblib.load(ml_models/label_region_code.pkl), decoration_code: joblib.load(ml_models/label_decoration_code.pkl) } def predict_unit_price(feature_dict): floor_level label_encoders[floor_level].transform([feature_dict[floor_level]])[0] region_code label_encoders[region_code].transform([feature_dict[region_code]])[0] decoration_code label_encoders[decoration_code].transform([feature_dict[decoration_code]])[0] features np.array([ feature_dict[area], feature_dict[bedrooms], feature_dict[living_rooms], feature_dict[bathrooms], floor_level, feature_dict[building_age], region_code, decoration_code, feature_dict[region_price] ]).reshape(1, -1) predicted_unit_price model.predict(features)[0] return predicted_unit_price注意预测时仍然要做和训练时一样的编码逻辑否则单个新数据进来会报“类别代码不存在”或者“特征数量不匹配”的错误。5.3 房源管理模块与后台设计房源管理模块以Django Admin为主会省力很多。你在admin.py里注册模型然后配置list_display和list_filterfrom django.contrib import admin from .models import HouseInfo admin.register(HouseInfo) class HouseInfoAdmin(admin.ModelAdmin): list_display (title, region, area, total_price, unit_price, building_age) list_filter (region, decoration, floor_level) search_fields (title, region, community)这样你就拥有了一个可以直接录入、编辑、删除房源数据的后台不用再手写一套管理页面。答辩时直接打开Admin后台给评委展示“我这个系统具备完整的数据管理能力”非常直观。但要注意Admin是默认的管理界面如果你想要更个性化的管理端比如只看部分字段、按条件批量修改可以用Django的表单和视图来补充毕设阶段做一个可用的管理页就足够。6. 数据库设计与查询优化的实践经验这一章单独拎出来讲因为数据库是很多同学的短板挂着MySQL的名头实际只会做一个单表查询。6.1 核心表结构参考以house_info表为例一个相对规范的表结构大概是这样字段名类型说明idint primary key auto_increment主键communityvarchar(100)小区名称regionvarchar(50)所在区域boardvarchar(50)板块total_pricedecimal(12,2)总价万元unit_pricedecimal(10,2)单价元/平方米areadecimal(10,2)面积平方米bedroomstinyint卧室数living_roomstinyint客厅数bathroomstinyint卫生间数floor_levelvarchar(20)楼层区间decorationvarchar(20)装修情况building_ageint楼龄年longitudedecimal(10,6)经度latitudedecimal(10,6)纬度created_atdatetime default current_timestamp入库时间用Django的模型类定义时注意decimal字段要指定max_digits和decimal_placesclass HouseInfo(models.Model): community models.CharField(max_length100) region models.CharField(max_length50) board models.CharField(max_length50) total_price models.DecimalField(max_digits12, decimal_places2) unit_price models.DecimalField(max_digits10, decimal_places2) area models.DecimalField(max_digits10, decimal_places2) bedrooms models.SmallIntegerField() living_rooms models.SmallIntegerField() bathrooms models.SmallIntegerField() floor_level models.CharField(max_length20) decoration models.CharField(max_length20) building_age models.SmallIntegerField() longitude models.DecimalField(max_digits10, decimal_places6, nullTrue, blankTrue) latitude models.DecimalField(max_digits10, decimal_places6, nullTrue, blankTrue) created_at models.DateTimeField(auto_now_addTrue)6.2 查询性能调优数据量不大的时候Django默认的ORM查询没问题但不要为了偷懒写所有数据一次性load到内存再过滤。比如区域均价统计错误写法list(HouseInfo.objects.all())然后在Python内存里循环累加正确写法用annotate配合聚合函数让MySQL帮你去重和计算。from django.db.models import Avg, Count region_stats ( HouseInfo.objects .values(region) .annotate(avg_priceAvg(unit_price), cntCount(id)) .order_by(-avg_price) )还有一点如果查询频繁按region筛选给region字段加个索引db_indexTrue价格排序的话给unit_price加索引。索引不是越多越好但这两个常见的过滤排序字段加了基本没副作用。6.3 MySQL连接配置与中文乱码Django连接MySQL时在settings.py里需要配置好字符集。用PyMySQL的话添加一行DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: house_price_db, USER: root, PASSWORD: yourpassword, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, }, } }然后记得在mysql连接时补一句init_command或者在MySQL建库时指定CREATE DATABASE house_price_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;乱码问题绝大多数是数据库建错了字符集或者连接串没带charset造成的。项目启动后先往库里手动插一条中文数据测试能正常显示再继续往下开发。7. 毕设答辩高频问题与调试避坑手册这里整理的是我长期观察下来毕设答辩现场最容易“爆”的问题每一个背后都有活生生的翻车案例。7.1 答辩评委最爱问的十个问题1. 你的数据是从哪里来的这是第一大高频问题所有人都被问过。回答思路说清楚原始数据来源、数据量大小、采集方式、清洗过程。如果数据是半模拟的也要坦诚说明规则生成的逻辑和合理性这反而显得你严谨。2. 数据量这么小比如只有几千条你凭什么认为模型预测结果可信回答思路强调模型评估指标例如R2在0.8以上说明在测试集上表现稳定同时自曝训练集的局限提出未来可通过扩大样本量提升模型泛化能力。这种回答既真诚又不失专业。3. 为什么选随机森林不选线性回归回答思路给出对比实验表格说明随机森林在R2、RMSE上优于线性回归并且对异常值和特征尺度更鲁棒。关键是让评委知道你做过了比较而不是只会用默认参数。4. 你的模型是怎么从Django里被调用的回答思路讲清楚“训练时保存模型文件运行Web服务时加载模型文件输入特征经过同样的编码转换后送入模型输出结果返回页面”这条链路。现场可以演示一次预测过程。5. 特征重要性是怎么算的有什么意义回答思路说明随机森林自带基于杂质减少的特征重要性评估并解释哪些特征对房价影响最大通常面积、区域、楼龄排前三结合业务面分析合理性。6. 如果用户输入的数据和训练集分布差异很大模型会怎样回答思路承认模型会有局限可以增加“预测置信度”提示或“输入范围限制”来规避异常输入但本质问题是训练数据覆盖度不足这是数据驱动模型共有的困难。7. 系统有哪些扩展点回答思路可以提未来接入房价时间序列、引入地理位置的POI数据、接入实时爬虫管道、用深度学习模型做图像估值等。扩展点要合理不要漫无边际吹牛。8. 你做了哪些安全性措施回答思路Django自带的CSRF防护、ORM参数化查询防SQL注入、后台管理需要登录、限制用户输入长度等都是可以讲的点。9. 为什么做Web系统而不直接做一个离线脚本回答思路强调“系统”意味着可视化、可交互、多用户视角这也是毕设题目要求“设计与实现”的本意所在。10. 预测结果可视化是用什么做的回答思路用ECharts做的后端只负责提供数据前端渲染图表。思路清晰的话还可以顺手讲一句“图表组件都做了自适应的响应式布局”。7.2 开发和调试中的七大常见坑坑1数据导入时报“Unknown column”原因CSV里的列名和Django模型字段名对不上。解决先打印CSV的表头和模型字段逐个对照创建一个字段映射字典而不是靠猜。坑2模型预测时维度不匹配原因训练时候的特征顺序和预测时候构造的特征顺序不一致。解决写一个get_feature_vector函数严格按训练时的feature_cols顺序构造数组每次改动特征列表时同步更新这个函数。坑3LabelEncoder训练完、预测时遇到没见过的类别比如测试集里没有某个区域但用户输入了这个区域。解决用encoder.classes_检查类别覆盖范围预测时先判断是否在已有类别中不在的话归入“其他”类别。坑4ECharts图表不显示90%的原因是div容器没有设置高度或者初始化图表的JS代码在DOM加载之前执行。解决给图表容器一个显式的height比如600px并且把初始化代码放在window.onload或者$(document).ready里。坑5Django找不到模板文件原因settings里没有配置DIRS或者模板文件没有放在正确的应用目录下。解决在settings.py中确认TEMPLATES [ { BACKEND: django.template.backends.django.DjangoTemplates, DIRS: [BASE_DIR / templates], APP_DIRS: True, ... } ]坑6ORM查询时N1次数据库查询比如循环中调用关联表查询。解决使用select_related或prefetch_related优化或者直接values()拿到聚合结果。坑7页面预测按钮转圈但后台没有报错也不返回结果这类问题通常在视图函数内部抛了异常但Django对非Debug模式返回了500页面或空白。解决开发阶段把settings里的DEBUG设置成True让错误页显示具体堆栈再不行就在视图的第一行加日志print逐段排查哪一步断了。7.3 代码讲解类的演示技巧答辩展示项目时代码讲解环节很容易变成“照着PPT念代码”。我见过讲得好的同学都是按这个顺序讲的先打开项目目录结构讲清每个模块的作用让评委形成全局认知然后打开模型训练的脚本快速展示数据读取到模型保存的流程重点讲一句“这里我做了一个特征转换是为了让类别特征能被模型识别”再打开Django视图函数演示一次完整的预测请求配合页面运行展示最后打开数据可视化页面点不同的图表说清楚每个图在设计时想表达什么结论。整个过程不要超过六到八分钟剩下的时间留给评委提问。评委问问题时能答上来的就简洁回答答不上来的不要瞎编诚实地说“这块我在开发中还没有深入考虑后续可以做进一步扩展”比硬撑着好得多。8. 文档和配套材料的准备策略毕设文档的重要性不亚于代码本身。评委花在文档上的时间比看代码的时间多得多。文档写得乱、图表缺失、协议不清楚代码再漂亮都会被扣分。8.1 论文或设计文档的章节建议一套标准的结构可以按这个框架走引言与背景说明房价分析的现实意义引入“传统估价方法效率低、主观性强”的问题点相关技术综述简要介绍Django框架、MySQL、回归模型、数据可视化技术需求分析分为功能需求和非功能需求功能需求条目化列清楚系统设计给出架构图、功能模块图、数据库ER图、接口设计系统实现按数据采集、数据处理、模型构建、系统功能四块每块配核心代码和运行截图系统测试功能测试用例表加上预测模型的评估指标表总结与展望客观总结系统完成内容提出不足和改进方向。8.2 技术文档的三个加分点写清楚实验环境版本。Python 3.10、Django 4.2、MySQL 8.0、scikit-learn 1.3等版本号写清楚别人复现时不容易踩兼容坑。画一张数据E-R图。毕设文档里数据库设计的篇幅要足够。用表格列出每张表的字段、类型、约束、说明再画一张简单的实体关系图这部分是评委快速判断你项目“有没有含金量”的快捷方式。做一个预测误差对比表。在模型章节里放一张这样的表模型R2MAERMSE结论线性回归0.722340.53128.7精度一般随机森林0.861570.22210.3精度较优XGBoost0.881435.62078.9略优于随机森林但训练耗时更长然后给一句“综合考虑预测精度和可解释性本项目最终选择随机森林作为核心预测模型”这就是完整的选型逻辑。我看到太多文档写得像流水账全是功能罗列没有设计思路。要把每一处关键设计都解释清楚——为什么字段这么设计、为什么选这个模型这才是“设计与实现”的真正内涵。9. 最后的几点个人体会跟这个题目打交道这么久我最大的感受是二手房价预测系统这个题目本身不难但它是一个很好的“能力放大器”。你用心打磨数据、老老实实做特征工程、把系统每一层梳理通那么在答辩现场你的底气和那些只把代码跑通就完事的同学是完全不同的——因为你对每一个环节都知道“为什么”。如果时间紧张优先顺序应该是数据清洗 模型可用性 可视化图表 管理端功能 额外扩展功能。先把主干做扎实再考虑花活。这个小项目未来能延伸的方向也很明确把静态回归模型换成对时间序列的训练加入房源挂牌时长和带看次数这类过程数据或者爬取周边基础设施的热点数据做特征扩展。已经有一个可用的底子在后续对接真实的业务场景会顺畅得多。最后再分享一个实际管用的小技巧开发期间把每个版本的模型文件和评估指标都留个备份备注好“第几版、用了哪些特征、R2是多少”。我见过很多同学调参调着调着就忘了哪个效果最好有记录的话答辩时可以直接讲“我尝试了多次调优最终保留了一组最优参数”——这句话的含金量评委一听就懂。