基于Python Django与Selenium的旅游景点可视化分析系统实战

每年三四月份，身边总有一批学弟学妹跑来问毕业设计怎么做，十个里有八个开口就是“旅游数据分析”“景点可视化”。说实话，这个方向本身不算新，真正拉开差距的是两点：一是数据从哪来，二是系统能不能让人眼前一亮。今天分享的这套基于 Python Django 与 selenium 的旅游景点可视化分析系统，就是冲着这两个痛点去做的。它把真实景点数据的采集、清洗、入库、分析、可视化串成一条完整链路，最终落成一个智慧文旅大数据驾驶舱风格的大屏页面，既能当毕业设计交差，也能作为入行大数据可视化方向的一份实战参考。

这套系统的核心逻辑并不复杂：用 selenium 模拟真实浏览器行为去抓取旅游平台公开的景点数据，拿到数据后由 Django 提供后台服务和接口，再用 ECharts 把景点热度排行、评分分布、区域特点等内容渲染成大屏组件。我之所以强调 selenium，是因为现在大多数旅游网站的列表页和详情页都依赖 JavaScript 动态渲染，直接用 requests 只能拿到一个空壳 HTML，解析不出任何有效信息。把这一点想清楚，整个项目的技术路线就顺了。

适合看这篇文章的人，主要是正在准备计算机毕业设计的学生，以及对 Python 数据采集、Django 后端、大屏可视化整个链路感兴趣的朋友。如果你已经有 Django 基础，那这篇更像是帮你把“采集端怎么和业务系统融合”这一层补完整；如果你是零基础起步，按照文中的模块拆解一步步搭，也能在两周内跑通核心功能。

1. 项目整体设计与方案选型

1.1 核心需求拆解

动手之前，先把需求想清楚。旅游景点可视化分析系统的本质，是回答几个问题：哪些景点热度最高？不同城市的景点分布如何？景点评分和评论量之间有没有关联？游客更关注门票价格还是体验评价？把这些业务问题翻译成技术语言，就是数据采集、多维分析、可视化展示三件事。

考虑到这是毕业设计场景，系统还需要满足几个隐性要求：演示效果好、工作量可量化、技术栈有说头。演示效果好意味着大屏不能只是几个表格堆在一起，得有地图、排行、趋势图这些一眼就能看出“智慧文旅”味道的组件；工作量可量化意味着采集、清洗、建模、接口、前端、部署每一层都要有明确的产出；技术栈有说头则意味着选型要能自圆其说，讲得出为什么用 selenium 而不是 requests，为什么用 Django 而不是 Flask。

1.2 技术选型背后的取舍逻辑

Python 是数据采集和分析领域的事实标准，生态完善，写起来快，这点不用多说。Django 作为后端框架，自带 ORM、Admin 后台、认证体系和模板引擎，对于毕设项目来说，省去了大量重复造轮子的时间。有人可能会问，Flask 不是更轻量吗？话是没错，但 Flask 的路由、ORM、认证都要自己拼装，项目一复杂就会变得零散，Django 的一体化结构反而更适合这种“前中后完整”的作业形态。

selenium 的选择在标题里已经点出来了，但要展开说明的是它的真实价值。旅游平台的数据往往藏在滚动加载、点击展开、Tab 切换这些交互后面，selenium 可以完整驱动浏览器渲染页面，再配合 WebDriverWait 等待关键元素出现，就能稳定拿到渲染完成后的数据。相比之下，requests + BeautifulSoup 的组合虽然轻，但对动态页面的处理需要额外分析 XHR 接口，一旦接口参数带加密逻辑，破解成本会直线上升。

可视化端采用 ECharts，这一点基本没有争议。它不是功能最强大的图表库，但胜在开箱即用，地图、折线图、柱状图、饼图、词云都覆盖了，而且社区案例极其丰富，对大屏场景的适配也非常成熟。

1.3 系统架构与数据流向

整套系统的结构可以划分为四层。采集层用 selenium 抓取公开数据，清洗后通过 Django ORM 写入 MySQL；持久层就是数据库中的几张核心表，记录景点基础信息、评分评论、区域归属等；业务层由 Django 提供 JSON 接口，按大屏组件的数据需求聚合数据；展示层则是独立的大屏前端页面，通过 Ajax 定时拉取接口，交给 ECharts 渲染。

数据流向是一条直线：网页 → selenium → 清洗脚本 → MySQL → Django ORM → JSON API → ECharts。每一层只依赖相邻层，替换成本低。比如你不想用 selenium，可以改成分析 XHR 接口抓 JSON，只需要替换采集层，后面所有内容都不受影响。这也是我刻意保持分层独立的原因，不管是做毕设还是以后做工程，这种解耦都能带来很大的维护便利。

2. 数据采集：selenium 抓取与数据清洗实战

2.1 为什么动态页面必须用浏览器驱动

很多初学者会遇到一个困惑：明明浏览器里能看到景点名称和评分，用 requests 去请求同样的 URL 却拿不到数据。这里的关键在于，很多旅游平台的数据不是写死在 HTML 里的，而是页面加载后由 JavaScript 调用接口动态填充的。你直接用 requests 拿到的是原始 HTML 骨架，数据根本不包含在内。

解决思路有两条。一条是抓包分析 XHR 请求，直接请求数据接口，优点是速度快、不依赖浏览器环境，缺点是很多平台在接口里加了签名参数、风控策略甚至验证码，逆向成本不小。另一条就是 selenium，它把 Chrome 或 Edge 当成一个“真人在操作的浏览器”，页面怎么渲染、数据怎么加载，它就怎么执行，拿到的一定是最终结果。这条路的代价是速度慢、资源占用高，但在毕设和中小规模数据采集场景里，稳定性远比速度重要。

2.2 采集脚本的核心实现

这里给出一个采集脚本的骨架。先说准备工作：安装 selenium 之后，还需要下载对应版本浏览器的 driver，比如 Chrome 就用 chromedriver，并且把 driver 所在目录加入系统 PATH，或者直接在代码里指定 executable_path。

python复制from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument('--headless=new')  # 无头模式，服务器上运行
options.add_argument('--disable-gpu')
options.add_argument('--no-sandbox')
options.add_argument('--disable-blink-features=AutomationControlled')
options.add_argument('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')

driver = webdriver.Chrome(options=options)
wait = WebDriverWait(driver, 10)

def fetch_spot_list(url):
    driver.get(url)
    # 等待列表容器出现
    wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, '.spot-item')))
    items = driver.find_elements(By.CSS_SELECTOR, '.spot-item')
    data = []
    for item in items:
        name = item.find_element(By.CSS_SELECTOR, '.name').text.strip()
        score = item.find_element(By.CSS_SELECTOR, '.score').text.strip()
        comments = item.find_element(By.CSS_SELECTOR, '.comments').text.strip()
        # 缺失字段兜底
        data.append({
            'name': name,
            'score': float(score) if score else 0.0,
            'comments': int(comments.replace('条评论', '')) if comments else 0,
            'url': item.find_element(By.CSS_SELECTOR, 'a').get_attribute('href')
        })
    return data

有几个细节值得注意。一是 AutomationControlled 这个参数，很多网站会检测 window.navigator.webdriver 的值来决定是否返回加密数据，去掉这个标记能显著降低被识别为机器人的概率。二是等待条件一定要用 expected_conditions，而不是傻乎乎地 time.sleep(5)，页面加载快慢受网络影响很大，固定等待要么浪费时间要么等不到位。三是文本解析时用 replace 把“条评论”这类干扰词去掉再做类型转换，否则 int() 会直接报错。

2.3 数据清洗与入库

抓下来不等于能直接用。景点名称可能有首尾空格、评分可能为空、评论数可能是“1.2万”这种带单位的文本，这些都要在入库前统一处理。我一般用 pandas 做清洗，代码量少，逻辑也直观。

python复制import pandas as pd
from sqlalchemy import create_engine

df = pd.DataFrame(raw_data)
df['name'] = df['name'].str.strip()
df['comments'] = df['comments'].apply(
    lambda x: int(float(x.replace('万', '')) * 10000) if '万' in x else int(x)
)
df['score'] = pd.to_numeric(df['score'], errors='coerce').fillna(0.0)
df = df.drop_duplicates(subset='name').reset_index(drop=True)

engine = create_engine('mysql+pymysql://user:password@localhost:3306/tourism?charset=utf8mb4')
df.to_sql('t_spot', engine, if_exists='replace', index=False)

清洗规则里最容易被忽略的是“重复”。同一个景点可能在不同列表页出现多次，直接入库会导致后端统计时数值翻倍。所以我在清洗脚本里加上了按景点名去重的逻辑，宁可少几条，不能多几条脏数据。

把清洗好的数据导入 Django 管理的 MySQL 之后，还要再检查两件事：一是编码，MySQL 连接串里必须带 charset=utf8mb4，否则中文景点名很容易变问号；二是字段类型，Django 的模型字段和 pandas 推断出来的类型可能有出入，比如评论数字段在 pandas 里是 int64，但到了 Django 这边如果模型定义的是 IntegerField 也会出问题，最稳妥的方式是先用 Django 的 ORM 写一条数据测试，确认读写都正常再批量导入。

3. Django 后端设计与数据接口实现

3.1 数据库模型设计

Django 的 ORM 让建表这件事变得非常简单，但模型设计的好坏直接决定后面写接口的复杂度。拿这套系统来说，我设计了四张核心表：景点信息表、区域表、评论表、用户表（用于登录）。

景点信息表存景点名称、所属城市、评分、评论数、门票参考价、热度权重、简介和封面图 URL。区域表存省、市、区的层级关系，方便大屏做地图下钻。评论表存用户对景点的主观评价文本，可以用来做情感分析或词云展示。用户表就是 Django 自带的 auth.User，再加上一个 Profile 扩展表，用来做一些基础的访问权限控制。

python复制from django.db import models

class Region(models.Model):
    province = models.CharField(max_length=50)
    city = models.CharField(max_length=50)
    district = models.CharField(max_length=50, blank=True)

    class Meta:
        db_table = 't_region'
        unique_together = ('province', 'city', 'district')

class Spot(models.Model):
    name = models.CharField(max_length=200, unique=True)
    region = models.ForeignKey(Region, on_delete=models.CASCADE, related_name='spots')
    score = models.FloatField(default=0)
    comments = models.IntegerField(default=0)
    ticket_price = models.FloatField(default=0)
    hot_value = models.FloatField(default=0)
    summary = models.TextField(blank=True)
    cover_url = models.URLField(blank=True)

    class Meta:
        db_table = 't_spot'
        ordering = ['-hot_value']

一个容易被忽略的细节：给 Spot 模型的 name 字段加了 unique=True。这个唯一约束不仅保障了数据一致性，也提醒采集层先查重再插入，形成双向约束。另外，ForeignKey 的 related_name 一定要起好名字，否则用该字段查询数据时默认名混乱，写 API 时很别扭。

3.2 核心接口设计与聚合计算

大屏上每个图表背后都是一个或多个数据接口。接口要返回的数据通常不是原始的景点记录，而是聚合统计结果。比如“热门景点 Top10”需要按热度排序后取前十条，“各城市景点数量分布”需要按城市分组计数，“评分区间分布”需要把评分切成几个区间再统计数量。

这些聚合逻辑在 Django 里用 ORM 的 annotate 和 values 组合很容易实现，完全不用写 SQL。我习惯把读写和聚合逻辑封在 service 层，View 里只负责取参数、调 service、返回 JsonResponse。

python复制from django.db.models import Count, Avg
from .models import Spot

def hot_rank(limit=10):
    qs = Spot.objects.order_by('-hot_value')[:limit]
    return [{
        'name': s.name,
        'city': s.region.city,
        'hot_value': s.hot_value,
        'score': s.score,
    } for s in qs]

def city_distribution():
    rows = Spot.objects.values('region__city').annotate(count=Count('id'))
    return [{'city': r['region__city'], 'count': r['count']} for r in rows]

def score_distribution():
    bins = [(4.5, 5.0), (4.0, 4.5), (3.5, 4.0), (0, 3.5)]
    result = []
    for low, high in bins:
        cnt = Spot.objects.filter(score__gte=low, score__lt=high).count()
        result.append({'range': f'{low}-{high}', 'count': cnt})
    return result

一定要注意 values 和 annotate 的先后顺序。values('region__city') 和 annotate(count=Count('id')) 谁在前，结果的分组依据完全不一样，写反了就会把每条记录当作一组，返回一堆 count=1 的数据，而且还不报错，排查起来非常头大。这个坑我踩过一次，建议在注释里写清楚：先 values 分组，再 annotate 聚合。

3.3 接口返回格式与权限控制

前后端交互格式我统一用 JSON，并且固定成一层结构：data 字段放数据，code 字段标记状态。这样前端在大屏里统一处理返回逻辑，也方便调试。View 层不建议直接把 QuerySet 塞进 JsonResponse，因为 QuerySet 里带的是模型对象，序列化容易出各种类型错误，还是先转成 dict 列表再返回最稳。

权限方面，如果只是毕设演示，可以在登录模块上做一层简单的 Token 校验。Django 内置了 session 认证，但前后端分离的大屏页面更常用 Token。我用的方案是在用户登录后生成一个随机 token 存到 Redis（也可以用 Django 缓存），前端请求接口时放到 Header 里，Django 侧写一个中间件统一校验。做这一步的目的不只是安全，也是答辩时一个可以拿出来讲的亮点。

4. 智慧文旅大数据驾驶舱大屏的实现

4.1 大屏布局与视觉设计

大屏的视觉设计直接决定演示效果。一个合格的驾驶舱页面，首先要层次分明，其次要有数据流动感。我常用的布局是：顶部通栏放系统标题和核心指标，中间左侧放城市排行、右侧放评分分布、中心放地图，底部放趋势折线图和词云。这种“四周围绕中心地图”的布局，在 1920x1080 的分辨率下效果最好。

配色上不要整那些花里胡哨的亮色，深色背景配青色和蓝色渐变是成熟方案，既贴合智慧文旅的主题，也和大屏场景的出彩度匹配。这里给出一个快速上手的 CSS 思路。

css复制body {
  background: #0b1b2b;
  color: #e6e6e6;
  font-family: 'Microsoft YaHei', sans-serif;
}
.panel {
  background: rgba(255, 255, 255, 0.05);
  border: 1px solid rgba(0, 229, 255, 0.2);
  backdrop-filter: blur(8px);
  border-radius: 8px;
  padding: 16px 20px;
}

很多初学者做出来大屏显得“假”，根因通常是数据太整齐或者控件太稀疏。解决方法是给每个组件设置单独的刷新间隔，比如 KPI 数字每 5 秒轮询一次，地图每 10 秒轮询一次，这样页面有种“实时在变”的感觉。再把无法采集到的字段做合理的模拟兜底，比完全空着好看得多。

4.2 ECharts 图表组件接入

接下来说 ECharts 的接入。ECharts 5 新增了按需引入的方式，但大屏项目直接全量引入更省事，反正毕设和实际演示对包体积不敏感。接入的基本步骤是先新建一个 div 容器，然后 init 图表，接着 setOption 配置，在页面销毁时记得 dispose。

javascript复制const chartDom = document.getElementById('hotRank');
const myChart = echarts.init(chartDom);
myChart.showLoading();

fetch('/api/dashboard/hot_rank/')
  .then(res => res.json())
  .then(res => {
    myChart.hideLoading();
    myChart.setOption({
      title: { text: '热门景点 Top10', left: 'center', textStyle: { color: '#fff' } },
      xAxis: { type: 'category', data: res.data.map(item => item.name) },
      yAxis: { type: 'value' },
      series: [{
        type: 'bar',
        data: res.data.map(item => item.hot_value),
        itemStyle: {
          color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [
            { offset: 0, color: '#00e5ff' },
            { offset: 1, color: '#003a6b' }
          ])
        }
      }]
    });
  })
  .catch(() => myChart.hideLoading());

这里有两个尺寸上的坑。一是容器 div 必须有宽度和高度，ECharts 初始化时读不到 0 尺寸就会渲染出空白画布。二是在页面刚加载时，如果 Tab 处于隐藏状态，图表渲染会失败或变形，所以初始化代码最好放在 window.onload 或 DOMContentLoaded 之后执行。

4.3 地图下钻与省市联动

地图是旅游数据分析的天然载体。ECharts 接入地图之前，需要先注册地图数据。项目里我用的是 GeoJSON 格式的中国省市地图数据，注册方式是把 JSON 通过 echarts.registerMap 挂载到图表中。如果你需要下钻到市级，思路是点击某个省份时，加载该省的市级 GeoJSON，再用 setOption 替换地图系列。

这种地图联动在大屏展示时非常加分，是答辩中的重点汇报内容。我在实践中是把省级 GeoJSON 和几个重点城市的 GeoJSON 提前下载到 static 目录，避免运行时拿不到数据。地图上的散点图代表当前选中城市的景点分布，散点大小代表热度，点击散点能联动右侧详情面板。

4.4 大屏数据刷新机制

大屏页面的数据不能是一锤子买卖，得有自动刷新机制。我采用了定时轮询方案，用一个 setInterval 统一调度多个组件的刷新函数。相比 WebSocket，轮询在大屏场景下够用且实现简单，不会引入额外依赖。

javascript复制const refreshTasks = {
  kpi: () => fetch('/api/dashboard/kpi/').then(renderKPI),
  rank: () => fetch('/api/dashboard/hot_rank/').then(renderRank),
  map: () => fetch('/api/dashboard/map/').then(renderMap)
};

function runAll() {
  Object.values(refreshTasks).forEach(fn => fn());
}

setInterval(runAll, 10000);

刷新时要注意连接次数。页面开久了浏览器的并发连接池可能会被占满，导致部分请求排队。我在大屏发布时给接口都开了一个简单的内存缓存，比如同一个统计接口 5 秒内重复请求直接返回缓存结果，这样既保证了轮询频率，也减少了数据库压力。

5. 让 selenium 不只是采集工具

5.1 定时任务与增量更新

如果系统上线或者演示完还要继续维护，数据就不能永远是那一批。selenium 在这里的角色可以更进一步：写成定时任务，定期重新抓取网页，对比数据库里的景点列表做增量更新。

解决方案是 Django 的 management command，也就是在应用目录下写一个自定义命令文件。命令里启动 selenium 抓数据，拿到新数据后先按 name 检查数据库，存在则更新评分和热度，不存在则新建记录。这个命令用系统 crontab 或者 Windows 计划任务每天跑一次，就能让系统的数据始终保持“新鲜感”，答辩时可以现场演示“数据是今天更新的”，这个效果非常直观。

5.2 自动巡检截图与异常告警

selenium 的另一个好用场景是给大屏做自动巡检。大屏页面依赖的接口如果挂了，展示效果会非常难看。我当时写了一个独立的巡检脚本：无头模式打开大屏页面，等待 5 秒，截图保存，然后用 Python 检查接口返回状态是否 200，数据是否为空。一旦发现异常，就往预留的邮箱发告警邮件。

这套机制虽然简单，但在演示前夜非常有用。有一次部署完大屏，我就是靠巡检脚本发现某个接口的 JSON 返回了个 NaN 值，影响了地图渲染，第一时间修掉了，第二天答辩才能顺利展示。如果没有这层保障，现场翻车是大概率事件。

5.3 资源释放与多线程限制

headless 模式虽然方便，但一定要记得退出浏览器进程。selenium 启动的是真实的 Chrome 进程，如果异常退出不调用 driver.quit()，Chrome 进程会一直挂在服务器上，积累多了内存直接爆掉。我习惯把采集逻辑包在 try/finally 里，确保无论成功失败都会退出。

另外，同一台机器不建议同时跑多个无头 Chrome 实例。一个实例大概占 300MB 内存，跑两三个可能还能撑，跑到五六个基本就把开发机拖垮了。定时任务里要对上一次任务是否还在运行做好判断，避免任务重叠。

6. 常见问题与排查技巧实录

6.1 采集阶段的典型故障

先聊最常见的“selenium 连不上浏览器”问题。新版本的 selenium 提供 Selenium Manager，多数情况下会自动找驱动，但国内网络环境下载 driver 很容易失败，建议手动去对应官网下载，命名要跟本机 Chrome 版本匹配。比如 Chrome 120 就找 120 系列的 chromedriver，版本不一致一定会报 session not created 之类的错误。

另一个高频故障是“元素找不到”。selector 写得再可靠，也会因为网页结构调整而失效。我的经验是把定位条件集中放在一个常量类里，不要散落在各个函数中，每次出现 NoSuchElementException 就去常量类里核对一次 selector。改成用 CSS_SELECTOR 而不是 XPath，因为大多数情况下 CSS 选择器更稳定，也更容易读。

网络超时也值得注意。网速慢、反爬严格会导致 wait 超时，此时不应该直接抛异常，而要捕获 TimeoutException 后重试。我习惯设置重试三次，每次间隔指数递增，避免对目标站点造成集中冲击。

6.2 Django 接口与数据异常的排查路径

接口返回 500 时，90% 的原因是数据里有类型问题。最常见的例子是从数据库读出的 null 被塞进了 JSON，前端拿到 undefined 直接渲染崩掉。建议在 service 层统一做一次清洗：null 转空字符串、None 转 0、NaN 转 0，宁可口径统一一些，别让脏数据一路流到前端。

还有一个容易踩的坑是 Django 查询集和原生 JSON 类型的互转。如果你在模型里用了 JSONField，序列化时要把 Python 的 dict 或 list 显式转换出来，否则 DjangoJSONEncoder 会帮你转出一些奇怪的字符串格式，前端解析时一脸懵。最稳妥的方式还是全链路字典化，不直接序列化模型对象。

6.3 部署阶段的注意点

大屏页面推荐部署到 Nginx 里做静态文件托管，Django 只负责接口。要保证的配置大概有三项：STATIC_ROOT 指向一个能写的目录，DEBUG 设为 False，ALLOWED_HOSTS 填上服务器的 IP 或域名。很多人本地跑得顺畅，一上服务器就白屏，原因大多是静态文件没 collectstatic，或者 Debug 开着但不认公网 IP。

数据库方面，如果使用 MySQL 5.7 及以上，要注意把事务隔离级别设成默认的 InnoDB REPEATABLE READ。太低可能引起聚合查询的脏读，太高会影响性能。deploy 前建议做一次数据库备份，整个项目最怕的不是代码 bug，而是数据丢了一版导致演示时无图可用。

6.4 常见问题速查表

7. 这套系统还能往哪些方向扩展

项目做完不代表结束，答辩或复盘时如果能讲讲后续扩展思路，会显得更有规划。第一个方向是引入大模型做智能分析，比如把采集到的用户评论丢给大模型做情感分析，自动生成“游客满意度关键词”词云或者“吐槽点”摘要，这块能直接和大模型微调、Agent 这些热点话题挂上钩。第二个方向是增加预测能力，基于历史热度数据做时间序列预测，用 Prophet 或者 LSTM 预测未来一周的热门景区，大屏上多一个“热度预测”模块。第三个方向是把单机采集改成分布式采集，引入 Redis 做任务队列，这是往“真实大数据工程”再走一步的方向。

以我自己的实践体会来说，这个项目最大的价值不在于某个技术点有多难，而在于它把一条完整的数据链路走通了。很多学生写项目都是写完接口就完事，数据靠手动造、页面靠截图充数，但这套系统真正做到了从“真实世界取数”到“大屏呈现”的闭环。如果你正在选毕设题目，或者正在为答辩的项目深度发愁，完全可以按这篇文章的脉络去搭一版。动手的过程中遇到任何问题，回到文中的问题排查表对应检查，多半都能找到答案。