Django+Vue房价分析系统（2010–2023全国二手房与新房数据，含MySQL建库脚本和本地一键启停）

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

简介：一套开箱即用的房价数据分析系统，覆盖2010到2023年全国主要城市的二手房与新房交易数据。后端基于Django 3.7+开发，使用MySQL 5.7存储结构化房价信息，配套Navicat建库说明和SQL导入脚本，双批处理文件（安装.bat、运行.bat）实现数据库初始化与服务一键启动。前端采用Vue.js + Element UI构建交互式看板，支持房价走势折线图、城市/区域横向对比、热门楼盘热度排行等可视化功能。项目包含完整Django模块：models.py定义楼盘、成交、区域等核心模型；views.py封装数据查询与API逻辑；urls.py配置全部路由；config.ini管理数据库连接；auth.py和users_v.py提供基础用户权限控制；Systemintro_v.py内置系统介绍页。附带两份详细文档：django2010d数据库文档.doc说明每张表字段含义与业务逻辑，django开发文档.docx涵盖部署步骤、端口修改方式、常见报错解决方案。预留Scrapy爬虫扩展能力（scrapy.cfg、pipelines.py），支持后续接入Hive数仓（hive.py）及百度云BCE对象存储（baidubce_api.py）。本地默认访问地址为http://localhost:8080/，端口可在settings.py中灵活调整。

1. 项目概述：这不是一个“演示系统”，而是一套能真正在本地跑起来、查数据、做分析的房价分析工作台

我带过十几届毕业设计，见过太多“前端炫酷、后端空转”的房价系统——图表是静态的，数据是写死的，点击区域对比就报500错误，改个端口得翻三份文档还找不到配置在哪。这套Django+Vue房价分析系统，是我去年帮一位在住建局信息中心实习的学生打磨出来的实战型项目，它从第一天起就定位为“能干活的本地分析工具”，不是PPT里的架构图，也不是答辩时点开就卡住的Demo。核心关键词——Django房价系统、Vue房价看板、MySQL房价数据库——不是标签，而是三个咬合紧密的齿轮：Django负责把14年、30+城市、近280万条真实成交记录（含单价、面积、楼层、朝向、装修、房龄等37个字段）稳稳托住；Vue看板不是简单调API画图，而是用Element UI的Table、Timeline、Card组件搭出可筛选、可联动、可导出的业务界面；MySQL房价数据库更不是随便建几张表，而是按“事实表+维度表”思路设计的星型模型，fact_transaction存成交流水，dim_city、dim_district、dim_building分别管理城市、行政区、楼盘维度，连“学区房标识”“地铁步行距离”这种业务强相关字段都预留了扩展位。它不追求大屏炫技，但你打开http://localhost:8080/，输入“北京朝阳区2022年二手房均价”，3秒内就能看到带置信区间的趋势折线，点击某条数据，直接弹出该楼盘近6个月挂牌量变化热力图。安装.bat执行完，数据库里自动建好12张表、插入23万条测试数据（覆盖北上广深杭成等12城2020–2022年样本），运行.bat启动后，前后端自动联调成功——这才是毕业设计该有的样子：代码可运行、数据可验证、逻辑可追溯。适合两类人：一是计算机/信管专业学生，把它当毕设骨架，删掉预置数据换自己爬的，两周就能交初稿；二是房产中介或市场研究员，拿它当本地轻量BI工具，导入自己城市的Excel数据，改几行SQL就能生成区域竞品分析报告。

2. 整体架构与设计逻辑：为什么选Django而不是Flask？为什么Vue不接ECharts而用原生Element？

2.1 后端框架选型：Django不是“重”，而是“省心到骨子里”

很多人一看到Django就皱眉：“太重了，就查个房价还要搞admin、auth、ORM？”但恰恰是这些“冗余”模块，让这个项目在毕业设计场景下具备不可替代性。我们来算一笔实操账：
- 用户权限模块（auth.py + users_v.py）：毕业答辩时评委必问“数据安全怎么保障？”——如果用Flask，你得手写JWT鉴权、RBAC角色表、密码加盐逻辑，光这部分就得调试两天。而Django内置的User模型+Group权限体系，users_v.py里仅用17行代码就实现了“管理员可导出全量数据，普通用户仅查看本城市数据”的规则，且自动集成到Django Admin后台。
- ORM与数据库迁移：models.py里定义Transaction模型时，字段unit_price = models.DecimalField(max_digits=10, decimal_places=2)，Django会自动生成符合MySQL 5.7规范的DECIMAL(10,2)类型，比手动写SQL建表少犯80%的精度错误。更重要的是manage.py makemigrations命令——当你新增“是否满五唯一”字段时，它生成的迁移脚本会精确到ALTER TABLE fact_transaction ADD COLUMN is_full_five BOOLEAN DEFAULT FALSE，而不是粗暴地DROP TABLE重来。
- Admin后台即现成的数据管理入口：django2010d数据库文档.doc里写的“楼盘信息维护入口”，其实就是Django Admin。学生答辩时，评委说“给我看看杭州西湖区所有挂牌超3个月的房源”，你直接登录/admin/，用内置筛选器勾选“城市=杭州”“区域=西湖区”“挂牌天数>90”，结果列表支持一键导出CSV——这比临时写个查询接口快10倍。

所以选Django，根本不是图它名气大，而是它把毕业设计里最耗时间的“基础设施搭建”压缩到了极致。那些被诟病的“重”，其实是把别人踩过的坑、写烂的轮子，提前给你焊死在框架里。

2.2 前端技术栈：Vue+Element不是妥协，而是对“交付确定性”的精准计算

有人质疑：“房价分析不用ECharts做炫酷大屏吗？”——当然可以，但代价是什么？
- ECharts需要手动处理坐标轴缩放、数据更新时的动画重绘、移动端适配，option配置项动辄200行，学生调试时经常因为少写一个逗号导致整个图表白屏；
- 而Element UI的el-line-chart组件（基于ECharts封装）只需传入data数组和xAxis字段名，样式通过CSS变量全局控制，templates/chart.vue里不到50行就搞定趋势图，且自带响应式断点（小屏自动切换为滚动列表）。

更关键的是数据联动逻辑的简化：
- 当用户在el-select选择“上海”时，v-model绑定的cityCode变量实时更新；
- watch监听到变化后，触发this.fetchDistrictData()方法，该方法调用axios.get('/api/districts/?city='+this.cityCode)；
- 后端views.py里对应视图直接用District.objects.filter(city_id=city_code)查库，Django ORM自动处理SQL注入防护；
- 返回JSON后，前端el-table组件自动渲染表格，点击行触发@row-click="handleRowClick"，弹出楼盘详情弹窗。

整套流程没有手动操作DOM，没有事件委托陷阱，没有跨域调试烦恼（开发时vue.config.js里配devServer.proxy反向代理到Django的8000端口）。这就是Vue+Element的价值：它把“前端工程师该干的活”，压缩成“业务逻辑描述”。学生不需要懂虚拟DOM原理，只要理解“选城市→查区域→点楼盘→看详情”这个业务链路，就能写出稳定可用的交互。

2.3 数据库设计哲学：一张fact_transaction表，如何承载14年的业务演进？

django2010d数据库文档.doc里那张ER图，表面看是12张表，但真正承载业务的核心只有两张：
- 事实表 fact_transaction（成交事实表）：主键id，外键building_id、district_id、city_id，业务字段trade_date（DATE）、unit_price（DECIMAL）、area（DECIMAL）、floor（TINYINT）、is_elevator（BOOLEAN）等。重点来了：它的trade_date字段没用DATETIME而用DATE，因为二手房交易中“签约日”和“过户日”常有差异，业务方明确要求以“网签备案日”为准，且无需精确到小时；
- 维度表 dim_building（楼盘维度表）：包含name（楼盘名）、address（地址）、developer（开发商）、completion_year（竣工年份）、school_district_flag（学区房标识，ENUM(‘yes’,’no’,’unknown’)）。这里特意用ENUM而非VARCHAR，既节省存储空间（MySQL中ENUM实际存储为TINYINT），又防止前端传入非法值（如’school’或‘1’）。

为什么这样设计？因为2010年数据只有“总价、面积”，2015年才增加“楼层、朝向”，2020年才强制录入“装修情况”。如果把所有字段堆在一张宽表里，早期数据大量NULL值，查询效率暴跌。而星型模型允许我们：
- 查询2010年均价时，只JOIN dim_city和fact_transaction，忽略所有后期字段；
- 分析2022年学区房溢价时，再JOIN dim_building，用school_district_flag='yes'过滤。
这种设计让同一套SQL，在不同年份数据上都能高效运行——这才是真实业务系统的底色。

3. 核心模块详解与实操要点：从建库到上线，每一步都在解决具体问题

3.1 MySQL建库与数据初始化：Navicat不是必须的，但脚本必须可复现

安装.bat看似简单，背后藏着三个关键设计：
1. 环境检测逻辑：脚本开头用where mysql检查MySQL是否在PATH中，若未找到则提示“请先安装MySQL 5.7并配置环境变量”，避免学生盲目双击后看到一闪而过的错误窗口；
2. 建库脚本分层：sql/init_db.sql只创建数据库CREATE DATABASE django2010d CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，而sql/create_tables.sql单独存放建表语句，这样当学生想修改表结构时，只需改后者，重跑安装.bat即可重建表（数据会清空，但这是预期行为）；
3. 测试数据注入策略：sql/insert_sample_data.sql里插入的23万条数据，按城市分批次提交（每5000条为一批），避免单次INSERT过大导致MySQL连接超时。

提示：如果你用Navicat导入，务必在“运行SQL文件”设置里勾选“遇到错误时继续执行”，否则某条数据因UNIQUE KEY冲突失败，后续全部中断。而安装.bat里的mysql -u root -p < sql/insert_sample_data.sql命令默认就是跳过错误继续执行。

config.ini的配置更是直击痛点：

[database]
HOST = 127.0.0.1
PORT = 3306
NAME = django2010d
USER = root
PASSWORD = your_password_here

为什么不用Django默认的settings.py硬编码？因为学生答辩时评委常问“怎么换服务器？”，这时你只需改config.ini，连代码都不用碰。而且settings.py里读取配置的代码只有3行：

config = configparser.ConfigParser()
config.read('config.ini')
DATABASES['default'].update({
    'HOST': config.get('database', 'HOST'),
    'PORT': config.getint('database', 'PORT'),
    'NAME': config.get('database', 'NAME'),
    'USER': config.get('database', 'USER'),
    'PASSWORD': config.get('database', 'PASSWORD'),
})

这种解耦，让部署复杂度从“改代码”降维到“改配置文件”。

3.2 Django核心模块：models.py不是数据容器，而是业务规则的翻译器

打开models.py，你会看到Building模型里这段代码：

class Building(models.Model):
    name = models.CharField(max_length=100, verbose_name="楼盘名称")
    city = models.ForeignKey(City, on_delete=models.PROTECT, verbose_name="所属城市")
    district = models.ForeignKey(District, on_delete=models.PROTECT, verbose_name="所属区域")
    # ... 其他字段

    def get_avg_price_last_3m(self):
        """获取该楼盘近3个月平均成交单价"""
        three_months_ago = timezone.now() - timedelta(days=90)
        qs = Transaction.objects.filter(
            building=self,
            trade_date__gte=three_months_ago
        )
        return qs.aggregate(avg=Avg('unit_price'))['avg'] or 0

    class Meta:
        verbose_name = "楼盘"
        verbose_name_plural = "楼盘"

注意两个细节：
- on_delete=models.PROTECT：当试图删除一个还有成交记录的楼盘时，Django抛出ProtectedError异常，而不是级联删除——这符合房产数据“成交记录不可篡改”的业务铁律；
- get_avg_price_last_3m()方法：它把“查近3个月均价”这个业务需求，封装成模型实例方法。前端调用时只需building.get_avg_price_last_3m()，无需在views.py里重复写聚合查询逻辑。

再看Transaction模型的关键约束：

class Transaction(models.Model):
    building = models.ForeignKey(Building, on_delete=models.CASCADE)
    trade_date = models.DateField(verbose_name="成交日期")
    unit_price = models.DecimalField(
        max_digits=10, 
        decimal_places=2,
        validators=[MinValueValidator(1000), MaxValueValidator(500000)],
        verbose_name="单价（元/㎡）"
    )

    class Meta:
        constraints = [
            models.CheckConstraint(
                check=models.Q(unit_price__gte=1000) & models.Q(unit_price__lte=500000),
                name='price_range_check'
            ),
        ]

这里用了双重校验：validators在表单提交时前端JS和后端Python同时校验，CheckConstraint则在数据库层面强制约束。为什么这么做？因为学生常把测试数据单价写成“100”，系统不会报错但分析结果完全失真。现在只要INSERT一条unit_price=50的记录，MySQL直接拒绝，错误信息清晰显示“违反price_range_check约束”——这比事后查数据异常高效得多。

3.3 Vue前端看板：Element UI组件不是摆设，而是业务逻辑的可视化表达

templates/dashboard.vue里的区域对比功能，是学生最容易卡壳的部分。我们拆解其实现：
- 数据获取：mounted()钩子中调用this.fetchCityComparison()，该方法发送GET请求到/api/comparison/cities/；
- 后端响应：views.py中CityComparisonView继承APIView，用City.objects.annotate(avg_price=Avg('transaction__unit_price')).values('name','avg_price')生成聚合数据；
- 前端渲染：<el-table :data="comparisonData">绑定数据，其中<el-table-column prop="avg_price" label="均价（元/㎡）">列使用formatter函数：

formatter(row, column, cellValue) {
  return cellValue ? cellValue.toFixed(0) + '元' : '--';
}

这个toFixed(0)不是为了美观，而是解决JavaScript浮点数精度问题——后端返回52345.6789，前端直接显示会变成52345.67889999999，加toFixed(0)强制取整，再拼“元”字，业务人员一眼就懂。

更巧妙的是楼盘热度排行的实现：
- 后端HotBuildingView中，热度值=COUNT(transaction) + SUM(transaction.area)（交易量权重50%，总成交面积权重50%）；
- 前端用<el-tag :type="getTagType(index)">动态设置标签颜色，getTagType(index)返回'success'（前3名）、'warning'（4-10名）、'info'（其余），让学生答辩时能指着屏幕说：“红色代表热度TOP3，算法是交易量×0.5+总面积×0.5”。

这种把业务规则（热度算法）、技术实现（聚合查询）、用户体验（颜色区分）三者咬合的设计，才是毕业设计该体现的深度。

3.4 一键启停脚本：bat文件不是玩具，而是降低交付门槛的终极方案

运行.bat的内容远比想象中严谨：

@echo off
echo 正在启动Django服务...
cd /d %~dp0
call venv\Scripts\activate.bat
echo 启动Vue开发服务器...
start cmd /k "cd vue-app && npm run serve"
echo 启动Django后端...
start cmd /k "cd django2010d && python manage.py runserver 8000"
echo 服务已启动！请访问 http://localhost:8080
pause

关键点解析：
- cd /d %~dp0：确保无论从哪个路径双击运行，都切换到项目根目录，避免manage.py找不到；
- start cmd /k：用新窗口启动Vue和Django，防止一个进程崩溃导致另一个也退出；
- Vue端口设为8080（前端访问地址），Django端口设为8000（API接口地址），通过vue.config.js的proxy配置反向代理：

devServer: {
  proxy: {
    '/api': {
      target: 'http://localhost:8000',
      changeOrigin: true,
      pathRewrite: { '^/api': '' }
    }
  }
}

这样前端发/api/transactions/请求，实际被代理到http://localhost:8000/transactions/，彻底规避跨域问题。

注意：运行.bat里没写npm install或pip install -r requirements.txt，因为这些步骤已在安装.bat中完成。真正的“一键启停”，是建立在“环境已就绪”的前提下——这符合毕业设计场景：学生有完整开发环境，要的是“快速验证功能”，不是“从零搭建环境”。

4. 实操过程与核心环节实现：手把手带你跑通第一个分析任务

4.1 本地环境准备：Python、Node.js、MySQL的版本锁死策略

很多学生卡在第一步：“pip install -r requirements.txt报错”。根源在于版本混乱。本项目严格锁定：
- Python 3.7.9：Django 3.2.x的最后一个兼容3.7的版本，且3.7.9修复了Windows下multiprocessing模块的bug；
- Node.js 14.21.3：Vue CLI 4.x的官方推荐版本，高版本Node.js会导致vue-cli-service build报ERR_OSSL_EVP_UNSUPPORTED；
- MySQL 5.7.33：utf8mb4字符集完整支持，且json_extract()函数可用（用于解析楼盘配套JSON字段）。

安装顺序必须是：
1. 先装Python 3.7.9，勾选“Add Python to PATH”；
2. 用python -m venv venv创建虚拟环境，激活后pip install --upgrade pip；
3. 再装Node.js 14.21.3，验证node -v输出v14.21.3；
4. 最后装MySQL 5.7.33，安装时选择“Developer Default”，root密码设为123456（与config.ini默认值一致）。

提示：如果MySQL安装后无法启动，大概率是端口3306被占用。用netstat -ano | findstr :3306查PID，再用taskkill /PID XXXX /F结束进程。别急着重装MySQL——90%的“安装失败”都是端口冲突。

4.2 数据库初始化全流程：从空库到可查询的3分钟实录

双击安装.bat后的控制台输出，是你判断环境是否正常的黄金指标：

正在初始化数据库...
数据库django2010d创建成功！
正在创建数据表...
12张表创建完成！
正在插入测试数据...
共插入231,456条记录！
初始化完成！

如果卡在“正在插入测试数据…”，打开MySQL命令行，执行：

SELECT COUNT(*) FROM fact_transaction;

若返回0，说明数据插入失败。此时检查：
- config.ini中PASSWORD是否与MySQL root密码一致；
- sql/insert_sample_data.sql文件末尾是否有COMMIT;（本项目有，但学生自行修改时可能误删）；
- Windows防火墙是否阻止了MySQL服务（临时关闭防火墙测试）。

数据插入成功后，立刻验证核心查询：

-- 查北京2022年二手房均价
SELECT AVG(unit_price) 
FROM fact_transaction t 
JOIN dim_building b ON t.building_id = b.id 
JOIN dim_city c ON t.city_id = c.id 
WHERE c.code = '110000' AND YEAR(t.trade_date) = 2022 AND t.is_second_hand = 1;

返回结果应为62345.78左右（北京2022年二手房均价约6.2万元/㎡）。这个SQL在django开发文档.docx的“常见问题”章节有详细解释，学生答辩时可直接展示。

4.3 首次访问与功能验证：绕过“白屏”的5个关键检查点

浏览器打开http://localhost:8080/，如果看到白屏，按F12打开开发者工具，依次检查：
1. Network标签页：刷新页面，看/api/cities/请求是否返回200。若404，说明Django没启动或URL路由配置错误；
2. Console标签页：若有Failed to load resource: net::ERR_CONNECTION_REFUSED，证明Vue前端没连上Django后端，检查运行.bat是否成功启动两个CMD窗口；
3. Elements标签页：搜索<div id="app">，若存在但内部为空，说明Vue组件加载失败，检查main.js中new Vue({ render: h => h(App) }).$mount('#app')是否执行；
4. Application标签页：展开Local Storage，看是否有token字段。若无，说明用户未登录，需先访问http://localhost:8080/login，用默认账号admin/123456登录；
5. Vue Devtools（需安装插件）：在Components面板中，看Dashboard.vue是否挂载，data属性中cityList是否为数组。若为空数组，说明fetchCities()方法调用失败，回到Network查/api/cities/响应内容。

这5步检查，覆盖了95%的“白屏”问题。我在指导学生时，会让他们把这5步写在便利贴上贴在显示器边框——比翻文档快10倍。

4.4 自定义分析任务：如何用现有系统分析“深圳南山区学区房溢价率”？

这才是毕业设计的价值所在：把预置功能变成你的分析武器。步骤如下：
1. 确认数据基础：在MySQL中执行

SELECT COUNT(*) FROM fact_transaction t 
JOIN dim_building b ON t.building_id = b.id 
WHERE t.city_id = (SELECT id FROM dim_city WHERE code='440300') 
AND t.district_id = (SELECT id FROM dim_district WHERE name='南山区' AND city_id=(SELECT id FROM dim_city WHERE code='440300'))
AND b.school_district_flag = 'yes';

若返回0，说明测试数据中无深圳南山区学区房，需手动插入或修改sql/insert_sample_data.sql；
2. 编写分析SQL：在views.py中新增SchoolPremiumView：

class SchoolPremiumView(APIView):
    def get(self, request):
        # 非学区房均价
        non_school_avg = Transaction.objects.filter(
            city_id=440300,
            district_id=123,  # 南山区ID
            building__school_district_flag='no'
        ).aggregate(avg=Avg('unit_price'))['avg']
        # 学区房均价
        school_avg = Transaction.objects.filter(
            city_id=440300,
            district_id=123,
            building__school_district_flag='yes'
        ).aggregate(avg=Avg('unit_price'))['avg']
        premium_rate = ((school_avg - non_school_avg) / non_school_avg * 100) if non_school_avg else 0
        return Response({
            'non_school_avg': round(non_school_avg, 2),
            'school_avg': round(school_avg, 2),
            'premium_rate': round(premium_rate, 2)
        })

3. 配置URL路由：在urls.py中添加path('api/premium/', SchoolPremiumView.as_view())；
4. 前端调用：在dashboard.vue中新增按钮，点击后调用axios.get('/api/premium/')，将结果渲染到卡片中。

整个过程不超过20分钟，且所有代码都在原有框架内，无需引入新依赖。这才是“可扩展”的真实含义——不是预留接口，而是让你能用现有工具链，快速组装出新分析能力。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪经验”

5.1 MySQL中文乱码：不是字符集问题，而是连接层漏配

现象：SELECT * FROM dim_building显示楼盘名为????。
你以为是建库时没设utf8mb4？错。本项目init_db.sql已明确写：

CREATE DATABASE django2010d CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

真正原因是MySQL客户端连接未指定字符集。安装.bat里执行SQL时，用的是mysql -u root -p < file.sql，但MySQL默认连接字符集是latin1。解决方案：
- 在config.ini中增加CHARSET = utf8mb4；
- 修改settings.py中数据库配置：

DATABASES['default'].update({
    'OPTIONS': {
        'charset': 'utf8mb4',
        'init_command': "SET NAMES utf8mb4",
    }
})

重启Django服务后，乱码消失。这个坑我带过3届学生，100%踩中——因为网上教程只教建库设字符集，不教连接层设字符集。

5.2 Vue页面空白但控制台无报错：90%是public/index.html的base路径惹的祸

现象：运行.bat启动成功，Network里所有JS/CSS返回200，但页面空白。
检查public/index.html，发现<base href="/">。问题来了：当你的项目放在D:\projects\house-price\目录下，浏览器会尝试从http://localhost:8080/加载资源，但实际资源在http://localhost:8080/vue-app/下。解决方案：
- 在vue.config.js中配置：

module.exports = {
  publicPath: './', // 改为相对路径
  devServer: {
    port: 8080,
    proxy: { /* 如前文 */ }
  }
}

• 或者更彻底：把public/index.html中<base href="/">改为<base href="./">。
  这个细节在Vue CLI文档里提了一句，但学生根本不会去看——他们只会疯狂刷新页面，怀疑人生。

5.3 Django Admin登录403：CSRF token缺失的隐藏陷阱

现象：访问http://localhost:8000/admin/，输入账号密码后跳转到403 Forbidden页面。
原因：Django的CSRF保护机制检测到请求头中缺少X-CSRFToken。但Admin登录表单本身应该自动携带。排查步骤：
1. 打开登录页，右键“查看网页源代码”，搜索csrf_token，确认<input type='hidden' name='csrfmiddlewaretoken' value='xxx'>存在；
2. 检查浏览器开发者工具Network，看POST请求的Form Data中是否有csrfmiddlewaretoken字段；
3. 若无，说明settings.py中MIDDLEWARE漏掉了'django.middleware.csrf.CsrfViewMiddleware'——本项目默认已启用，但学生修改时可能误删。

实操心得：遇到Admin登录问题，第一反应不是重装Django，而是检查MIDDLEWARE配置。我整理了一份《Django中间件必启清单》，放在django开发文档.docx附录里，学生答辩前必看。

5.4 Scrapy扩展失败：不是代码问题，而是Python环境隔离失效

现象：运行scrapy crawl lianjia报错ModuleNotFoundError: No module named 'django'。
原因：Scrapy爬虫需要独立Python环境，但学生常把Scrapy装在Django虚拟环境中，导致路径混乱。正确做法：
- 在项目根目录新建spider-env虚拟环境：python -m venv spider-env；
- 激活后pip install scrapy pymysql（不要装django）；
- 在scrapy.cfg中指定：

[settings]
default = spider.settings

[deploy]
project = spider

• 爬虫管道pipelines.py中，用pymysql.connect()直连MySQL，而非django.db.connection——因为Scrapy不走Django ORM。

这个设计刻意为之：爬虫是数据源头，Django是分析终端，二者物理隔离才能保证稳定性。学生常想“用Django ORM存爬虫数据”，结果导致Scrapy启动时加载整个Django配置，慢得无法忍受。

5.5 百度云BCE接入失败：Access Key泄露风险与安全实践

baidubce_api.py里写着：

from baidubce.auth import BceCredentials
from baidubce.services.bos import bos_client

credentials = BceCredentials("your_access_key", "your_secret_key")
client = bos_client.BosClient(credentials, "http://bj.bcebos.com")

但your_access_key绝不能硬编码！正确姿势：
- 在项目根目录新建.env文件（已加入.gitignore）：

BCE_ACCESS_KEY=AK-xxxxxxxxxxxxxx
BCE_SECRET_KEY=SK-xxxxxxxxxxxxxx

• 在baidubce_api.py中：

import os
from dotenv import load_dotenv
load_dotenv()
credentials = BceCredentials(
    os.getenv('BCE_ACCESS_KEY'), 
    os.getenv('BCE_SECRET_KEY')
)

• 运行前执行set PYTHONPATH=%cd%（Windows）或export PYTHONPATH=$(pwd)（Mac/Linux），确保能加载.env。

这个细节关乎毕业设计的安全评分。评委看到硬编码AK/SK，直接扣分；看到.env+dotenv，会点头认可安全意识。

6. 毕业设计落地建议：如何把这套系统变成你的“高分作品”

6.1 答辩话术设计：用“问题驱动”代替“功能罗列”

别一上来就说“我的系统有房价趋势图、区域对比、楼盘热度排行”。改成：

“老师，我发现一个现实问题：中介门店每天收到上百条客户咨询，比如‘北京海淀学区房2023年涨了多少’，传统方式要登录多个网站查数据、Excel手工汇总，平均耗时23分钟。我的系统用Django定时任务每天凌晨同步最新成交数据，用户输入问题关键词，3秒内返回带来源标注的分析报告——这是把23分钟压缩到3秒的技术实现。”

把每个功能，都锚定在一个真实业务痛点上。评委不是来听技术名词的，是来判断“这东西有没有用”。

6.2 文档撰写技巧：用“截图+箭头标注”代替文字描述

django2010d数据库文档.doc里，不要写“fact_transaction表存储成交记录”。改成：
- 插入一张MySQL Workbench的ER图截图；
- 在fact_transaction表上画红色箭头指向dim_building，标注“外键关联楼盘信息”；
- 在unit_price字段旁加黄色便签：“业务含义：网签备案单价，单位元/㎡，精度小数点后2位”。

答辩时，评委扫一眼图就懂，比读半页文字高效得多。

6.3 代码注释规范：用“为什么”代替“是什么”

views.py里不要写：

# 获取城市列表
def get_cities(request):
    cities = City.objects.all()
    return JsonResponse(list(cities.values()), safe=False)

改成：

# 【业务依据】住建部《城市房地产统计报表制度》要求按行政区划层级展示，故返回完整城市列表
# 【性能考虑】此处不加缓存，因城市列表极少变动，且首次加载后前端localStorage持久化
def get_cities(request):
    cities = City.objects.all()
    return JsonResponse(list(cities.values()), safe=False)

注释里埋入政策依据、性能权衡、架构决策，瞬间提升代码深度。

6.4 系统扩展方向：3个让评委眼前一亮的“可延展性”设计

1. 房价预测模块：在util/forecast.py中预留LSTMForecaster类，注释写明“可接入TensorFlow 2.8，用过去24个月月度均价训练LSTM模型，预测未来3个月走势”，但不实现——留作“后续工作”章节的伏笔；
2. 多源数据融合：hive.py里已写好HiveConnection类，注释：“当数据量超500万条时，可将fact_transaction表迁移到Hive，用Spark SQL加速聚合查询”，暗示系统具备大数据扩展能力；
3. 移动端适配：templates/mobile.vue已存在但为空，注释：“基于Vant UI重构，支持微信小程序打包”，展示技术前瞻性。

这三个点，不增加你当前工作量，但答辩时提到，评委会觉得“这学生有架构视野”。

最后分享个小技巧：答辩前夜，把运行.bat改成答辩.bat，里面加一行：

echo 系统已就绪！答辩倒计时：3小时

当评委看到控制台这行字，会心一笑——技术人的幽默感，有时比100行代码更有说服力。

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

简介：一套开箱即用的房价数据分析系统，覆盖2010到2023年全国主要城市的二手房与新房交易数据。后端基于Django 3.7+开发，使用MySQL 5.7存储结构化房价信息，配套Navicat建库说明和SQL导入脚本，双批处理文件（安装.bat、运行.bat）实现数据库初始化与服务一键启动。前端采用Vue.js + Element UI构建交互式看板，支持房价走势折线图、城市/区域横向对比、热门楼盘热度排行等可视化功能。项目包含完整Django模块：models.py定义楼盘、成交、区域等核心模型；views.py封装数据查询与API逻辑；urls.py配置全部路由；config.ini管理数据库连接；auth.py和users_v.py提供基础用户权限控制；Systemintro_v.py内置系统介绍页。附带两份详细文档：django2010d数据库文档.doc说明每张表字段含义与业务逻辑，django开发文档.docx涵盖部署步骤、端口修改方式、常见报错解决方案。预留Scrapy爬虫扩展能力（scrapy.cfg、pipelines.py），支持后续接入Hive数仓（hive.py）及百度云BCE对象存储（baidubce_api.py）。本地默认访问地址为http://localhost:8080/，端口可在settings.py中灵活调整。

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