基于Django和ECharts的房源数据分析可视化系统构建指南

1. 需求拆解：这个毕设项目的“数据底座”与“展示目标”怎么定

1.1 系统的三个核心模块：数据、分析、呈现

每年到毕业设计选题的时候，最容易踩的坑就是选一个“谁都在做、老师早看腻了”的方向。学生管理系统、图书管理系统、网上商城……这些题目不是不行，而是很难做出区分度。房源数据分析可视化系统能在这一类题目里跳出来，靠的不是技术多高深，而是它的数据天然贴近生活，展示结果直观，答辩时讲解成本低，而且技术栈刚好覆盖爬虫、后端、前端、数据库、数据分析，一条链路完整。

拆开来看，这套系统其实就三块：数据从哪里来、数据怎么存怎么算、结果怎么展示。对应到技术上就是 Requests 爬虫负责采集，Django 负责数据建模和接口，ECharts 或类似可视化库负责把分析结果渲染成图表。每一块单独拿出来都不算难，但把它们串成一个完整项目，这才是毕业设计该有的工作量，也正好是评委老师想看到的“系统完整性”。

1.2 数据颗粒度的选择：房源、区域、价格、户型怎么组合

做这个项目，第一步不是写代码，而是想清楚要分析什么。房源数据的常见维度包括小区名称、所在区域、户型、面积、朝向、楼层、挂牌价、租金、发布时间、关注人数等。毕设阶段不建议贪多，把核心字段控制在 10 个以内就够了，数据字段一多，清洗和展示的成本会迅速上升，最后反而每个点都讲不透。

我建议的分析维度可以固定为：区域分布、价格区间、户型占比、面积与价格的关系、房源数量随时间的变化。这五个维度刚好对应五张图，既有信息量又能形成“看板感”。答辩的时候就能按“数据总量多少、分布在哪些区域、价格集中段在哪、户型结构如何”这样一条逻辑线讲下去，比你堆二十个图表但说不清结论要强得多。数据源方面，优先找公开数据集或带官方接口的平台，如果不方便，就自己构造一份贴近真实分布的样例数据，爬虫部分作为技术演示保留即可。

2. 技术选型：Django + Requests + 可视化这套组合为什么值得抄

2.1 Flask、Scrapy、Django 之间的取舍

很多同学一上来就问，爬虫是不是该用 Scrapy，后端是不是该用 Flask？这个选择题其实没有标准答案，但放到毕业设计的场景里，Django 加 Requests 的组合有着非常现实的优势。

先看框架对比：

Django 在毕设里最大的价值，不是它的性能，而是它“自带工程化规范”。创建项目后自动分好 settings、urls、views、models、templates，老师一眼就能看出你有工程意识。Django 自带的 Admin 后台还能直接预览和管理房源数据，演示的时候省掉很多临时造数的时间。而 Requests 作为爬虫客户端，简单直接，能清楚展示请求头、参数、响应的处理流程，比 Scrapy 更适合用来做“教学级讲解”。

2.2 可视化方案的落地选择：ECharts 还是自研大屏

可视化部分不要自己去用 Canvas 硬画，也不要一上来就搞那些重量级 BI 工具，ECharts 是这个场景下最务实的选择。它基于 JavaScript，图表类型全，渲染流畅，支持动态数据推送，最关键的是社区案例多，遇到问题一搜就有答案。

当然，有些学校要求“可视化大屏”，这里要区分一个概念：大屏不是技术难点，而是布局和配色问题。ECharts 本身就能实现地图、折线图、柱状图、饼图、热力图，再配合 CSS Grid 或 Flex 布局把页面分成几个区块，顶部放标题和统计数字，中间放核心图表，底部放辅助图表，一个像模像样的可视化大屏就出来了。如果时间充裕，还可以用 Django 的模板系统直接渲染页面，不需要单独部署前端工程，整体链路更简单。

3. 爬虫与数据清洗：进入系统的第一道门槛

3.1 Requests 爬虫的正确姿势与合规边界

先说明一点，写爬虫一定要有边界意识。毕设项目里做爬虫，目的是演示技术能力，不是真的让你去暴力抓取某些平台的全部数据。实际操作时优先选择有公开接口的数据源，或者使用官方提供的测试数据，如果要抓取网页，也要控制频率、不要绕过登录和反爬机制，更不要用于商业用途。

Requests 的用法并不复杂，核心就是构建请求头、发送请求、解析响应。下面是一段典型的采集逻辑，用 Requests 请求一个房源列表页，再用 BeautifulSoup 解析出字段：

python复制import requests
from bs4 import BeautifulSoup
import time

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/120.0.0.0 Safari/537.36",
    "Accept-Language": "zh-CN,zh;q=0.9",
}

def fetch_house_list(url):
    resp = requests.get(url, headers=headers, timeout=10)
    if resp.status_code != 200:
        print(f"请求失败，状态码: {resp.status_code}")
        return []
    resp.encoding = resp.apparent_encoding
    soup = BeautifulSoup(resp.text, "html.parser")
    items = []
    for card in soup.select(".house-card"):
        item = {
            "title": card.select_one(".title").text.strip(),
            "region": card.select_one(".region").text.strip(),
            "price": card.select_one(".price").text.strip(),
        }
        items.append(item)
    return items

这段代码里有两个容易被忽略的小细节：resp.encoding = resp.apparent_encoding 是为了避免中文乱码；time.sleep 用于请求间隔，在没有写重试和限速逻辑的情况下，连续快速请求很容易触发对方的访问限制。

3.2 数据清洗的经典步骤

爬下来的数据不能直接入库，因为网页上的信息通常是带单位、带后缀的字符串。比如“7500元/月”“89.5㎡”“3室2厅”，这些字段如果作为字符串存进数据库，后面做统计时完全没有办法运算。清洗的目标就是把这些文本转成结构化数据。

以价格为例，需要去掉“元/月”这类单位，只保留数字；面积字段去掉“㎡”并转成 float；户型字段可以拆成室、厅两个独立属性。这个环节用 pandas 处理非常顺手：

python复制import pandas as pd

df = pd.DataFrame(raw_data)

# 价格清洗：去掉非数字字符
df["price"] = df["price"].str.replace("元/月", "").str.replace(",", "").astype(float)

# 面积清洗：保留数字部分
df["area"] = df["area"].str.replace("㎡", "").astype(float)

# 户型拆解：3室2厅 -> 室=3, 厅=2
df["bedroom"] = df["layout"].str.extract(r"(\d+)室").astype(float)
df["living_room"] = df["layout"].str.extract(r"(\d+)厅").astype(float)

# 去重
df = df.drop_duplicates(subset=["title", "region"])

# 缺失值处理
df = df.dropna(subset=["price", "area"])

清洗规则看着简单，但实际数据里经常出现“价格待定”“面积暂无”这类异常值，所以 dropna 之前最好先看一眼每个字段的缺失比例，不要无脑删除。如果缺失比例超过 30%，说明采集字段本身有问题，需要回到爬虫阶段检查选择器。

3.3 429 状态码的应对：限速、重试与异常处理

用 Requests 写爬虫，最先遇到的拦截信号大概率是 429 Too Many Requests。你不是被拉黑了，只是请求频率超过了对方允许的阈值。这时候最忌讳的做法是“拼命重试”，正确做法是退避重试。

python复制import time
import random

def request_with_retry(url, max_retries=3):
    for attempt in range(max_retries):
        try:
            resp = requests.get(url, headers=headers, timeout=10)
            if resp.status_code == 200:
                return resp
            if resp.status_code == 429:
                wait_time = 2 ** attempt + random.random()
                print(f"触发限流，等待 {wait_time:.1f} 秒后重试")
                time.sleep(wait_time)
                continue
        except requests.RequestException as e:
            print(f"请求异常: {e}")
            time.sleep(1)
    return None

为什么要用指数退避而不是固定等待？因为限流的一方通常也是按时间窗口计算频率的，指数退避能让你在尽量短的时间内恢复请求，又不会因为重试太频繁导致封禁时间越来越长。这个逻辑不仅能用在毕设里，工作后写任何调用第三方接口的脚本都用得上。

4. Django 后端：数据模型与接口层设计

4.1 数据模型与 ORM 设计

数据清洗完成之后，下一步就是建模。Django 的 ORM 是整个后端最值得展开讲的部分，因为它的模型设计直接决定了后续查询和展示的复杂度。

房源信息表建议按这样的结构设计：

python复制from django.db import models

class HouseInfo(models.Model):
    title = models.CharField(max_length=200, verbose_name="标题")
    region = models.CharField(max_length=50, db_index=True, verbose_name="区域")
    price = models.FloatField(verbose_name="价格")
    area = models.FloatField(verbose_name="面积")
    bedroom = models.IntegerField(null=True, blank=True, verbose_name="室")
    living_room = models.IntegerField(null=True, blank=True, verbose_name="厅")
    layout = models.CharField(max_length=20, blank=True, verbose_name="原始户型")
    source = models.CharField(max_length=100, blank=True, verbose_name="数据来源")
    created_at = models.DateTimeField(auto_now_add=True, verbose_name="抓取时间")

    class Meta:
        db_table = "house_info"
        ordering = ["-created_at"]
        verbose_name = "房源信息"

    def __str__(self):
        return self.title

有几个设计决策值得你写在论文里：db_index=True 加在 region 上，是因为后续按区域分组统计的查询一定会高频用到，不加索引的话数据量上来后查询会明显变慢；price 用 FloatField 而不是 CharField，是为了能在 ORM 里直接做聚合运算，否则每次都要在查询结果里再转一次类型。

建好模型后执行 makemigrations 和 migrate 生成数据库表。这里有个小建议，数据库不要只用系统默认的 SQLite，如果时间允许，换成 MySQL 或者 PostgreSQL，这会让项目在“大数据”方向上的表述更有说服力，也避免答辩时被问到“为什么不用 MySQL”时卡壳。

4.2 接口设计与定时任务

数据模型有了，接下来要提供接口给可视化页面调数据。Django 最常规的做法是写视图函数返回 JSON，配一个简单的 URL 路由。

python复制from django.http import JsonResponse
from django.db.models import Count, Avg
from .models import HouseInfo

def region_stats(request):
    stats = (
        HouseInfo.objects.values("region")
        .annotate(count=Count("id"), avg_price=Avg("price"))
        .order_by("-count")
    )
    return JsonResponse({"regions": list(stats)}, json_dumps_params={"ensure_ascii": False})

注意 json_dumps_params={"ensure_ascii": False}，不加这个参数，返回的 JSON 里中文就会变成 \uXXXX，前端能解析，但你在浏览器里直接看接口时特别难受，也显得不专业。

数据更新的问题也要考虑。爬虫只跑一次肯定不行，最好做成定时任务。Django 没有内置的定时调度能力，常见做法是配合系统的 crontab，或者引入 APScheduler。考虑到毕设的展示要求，我的建议是做一个“手动触发 + 定时触发”的混合方案：后台管理页提供“更新数据”按钮，同时通过 crontab 每天凌晨跑一次采集脚本。这样演示的时候可以手动点击立刻看到效果，日常又能保持数据的新鲜度。

5. 可视化大屏：数据怎么呈现才能让人一眼看明白

5.1 图表选择与页面布局

可视化不是把图表堆到页面上就行，而是要让看图的人在五秒内抓住重点。房源分析系统里，我建议这样分配：

• 顶部：总房源数、平均租金、最高租金、区域数量，四个数字卡片
• 中间主区：区域房源分布地图或柱状图，用来回答“房源集中在哪里”
• 右侧：价格区间分布直方图，用来回答“租金集中区间是多少”
• 底部左：户型占比饼图，用来回答“几室是主流”
• 底部右：面积与价格散点图，用来回答“面积和价格到底是什么关系”

如果拿不到带地理坐标的地图数据，可以用横向柱状图代替地图，效果同样直观，还免去地图数据文件的适配问题。ECharts 的柱状图、饼图、散点图是使用频率最高的三个类型，各自的配置项非常稳定，基本不会踩坑。

5.2 动态刷新与筛选联动的实现

静态图表做出来只是及格，加上联动筛选才能体现系统的设计感。实现思路是给页面上的图表绑定事件，比如点击柱状图的某个区域，下面的价格区间图、户型占比图就跟着切换成该区域的数据。

Django 端需要提供一个支持条件查询的接口：

python复制def filter_stats(request):
    region = request.GET.get("region", "")
    queryset = HouseInfo.objects.all()
    if region:
        queryset = queryset.filter(region=region)
    data = {
        "total": queryset.count(),
        "avg_price": queryset.aggregate(Avg("price"))["price__avg"],
        "distribution": list(queryset.values("region").annotate(c=Count("id"))),
    }
    return JsonResponse(data, json_dumps_params={"ensure_ascii": False})

前端用 ECharts 的 myChart.on("click", callback) 监听点击事件，拿到 region 参数后重新请求接口，再通过 setOption 更新图表。这套逻辑是可视化大屏最核心的交互模式，写清楚这一块，答辩时你就可以讲“用户点击某个区域，其他图表完成联动筛选”，这个功能点非常加分。

6. 从开发到答辩：那些容易翻车但没人提前告诉你的细节

6.1 部署与演示环境的坑

很多同学在本地跑得好好的，一到演示就出问题，原因几乎都是环境和数据问题。先说环境：Django 需要跑在虚拟环境里，这个应该是最基础的约定，但每年都有同学因为搞混了全局环境和虚拟环境，导致换台电脑后依赖全部丢失。建议项目根目录放一个 requirements.txt，用 pip freeze > requirements.txt 生成，换环境时一条 pip install -r requirements.txt 搞定。

数据问题更隐蔽。爬虫采集的数据是有实效性的，演示前一晚如果发现数据是空的，大概率是目标网站改版了或者自己的网络环境变了。稳妥的做法是维护一份“演示数据 JSON 文件”，在数据源不可用时一键导入数据库，保证答辩现场无论如何都能展示全套功能。

6.2 性能优化与代码结构加分项

数据量小的时候，什么代码都流畅，但答辩时老师很可能问“数据量大了怎么办”。这个问题并不需要你真的优化到百万级，但要有思路。核心点有两个：

第一，查询要避免 N+1 问题。用 ORM 查关联对象时，如果循环里反复查询数据库，数据量一大就会卡死。解决方式是在查询时用 select_related 或 prefetch_related 预加载关联数据。

第二，统计类接口要做缓存。区域分布、价格区间这些数据在分钟级以内不会变化，完全没必要每次请求都查一次数据库。Django 自带的 cache 就可以派上用场：

python复制from django.core.cache import cache

def get_region_stats():
    cached = cache.get("region_stats")
    if cached:
        return cached
    stats = HouseInfo.objects.values("region").annotate(count=Count("id"))
    cache.set("region_stats", list(stats), 300)
    return stats

这个代码往简历里写也是一句很实在的经验：接口平均响应时间从几百毫秒降到几十毫秒。别小看这个优化，它会让你的项目在“性能”这个维度上高出同组同学一截。

关于数据采集的合规性，再提醒一句：如果你的爬虫模块涉及第三方页面，在论文和演示 PPT 里一定要强调“仅用于学习研究，遵循 robots 协议，控制请求频率，不抓取非公开数据”，这既是学术规范，也是保护你自己。

从我带过的项目经验来看，这个题目做成型不难，难的是把每一个环节讲清楚。如果你正在做这个题目，建议按“数据采集 -> 数据清洗 -> 数据入库 -> 接口开发 -> 可视化展示 -> 项目部署”的顺序推进，每完成一个阶段就留好截图和代码备份。答辩前把系统从零到一完整跑一遍，确保换台电脑也能 5 分钟内启动成功，比临时抱佛脚改代码有用得多。

最后一个小建议：源码和数据库文件老老实实做好备份，别只放在电脑桌面。往届见过太多人在答辩前一周把项目删了、改坏了、合并冲突了，最后只能对着白屏干着急。技术上的边角料都能补，数据丢了才是真的欲哭无泪。