基于Python的携程旅游数据分析大屏：毕业设计全栈实战

又到了一年一度的毕业设计选题季。每年这个时候，我都能在论坛和私信里看到大量类似的问题：“学长，毕设选什么题目好啊？”“做一个管理系统是不是太low了？”“有没有既有技术含量又能在三个月内做完的题目？”说实话，这种问题背后透露出的是同一种焦虑——毕设这道关卡，既想拿个好成绩，又不想把自己折腾死在写代码的路上。

今天要拆解的这套“基于Python的携程旅游数据分析大屏系统”，就是我认为很适合作为计算机类毕业设计选题的方向。先别急着觉得“携程”两个字好像很商业，实际上这套项目把后端框架（Django）、动态页面爬虫（Selenium）、数据分析与机器学习、数据可视化大屏这几个核心模块串成了一条完整的工程链路。它解决的核心问题是：如何验证一个学生具备从数据采集、处理到展示输出的全栈工程能力，而这恰好是答辩评委最看重的东西。不管你是想做毕设、课程设计，还是单纯想给自己的简历增加一个能讲清楚的高质量项目，这篇内容都可以作为你的参考底稿。

1. 选题思路：为什么旅游数据分析大屏是毕业设计的“优等生”

1.1 这题目解决的到底是什么问题

首先要说清楚，这个项目不是“又一个旅游网站”。它的核心价值在于两个字——链路。从Selenium爬虫抓取携程上的景点、酒店、评论、价格数据开始，经过Pandas清洗，存入数据库，再由Django提供数据接口，最终用ECharts等可视化方案在大屏上展示出来，再由机器学习模块做人数预测和情感分析。这一整条链路是真实企业里数据处理流程的小型化再现。

我见过太多毕设项目，要么只做前端页面（静态数据写死），要么只做单一爬虫（数据爬完就完事了），这两种都很难让评委觉得“有深度”。而这个题目天然避免了这个问题，因为不管你拆开哪一层，都有东西可讲：爬虫怎么应对反爬？数据清洗怎么处理缺失值？Django的ORM怎么设计数据模型？大屏的海量图表数据如何实时刷新？任何一个问题都能在答辩时撑起五分钟的深入讨论。

1.2 技术栈覆盖度与答辩优势

我们再来看这个选题的技术覆盖范围。Python、Django、Selenium、Pandas、机器学习算法、ECharts或类似可视化组件，再加上可选的大模型/Agent增强模块。按照很多学校的评分标准，这些关键词几乎覆盖了数理基础、编程能力、工程实践、创新性四个维度的核心加分项。

答辩时最大的优势是什么呢？是可视化的冲击力。大屏数据面板在演示环节非常直观，一打开就能让评委看到地图分布、趋势曲线、排名列表、情感倾向等内容。相比之下，图书管理系统的页面再怎么做也只是表单增删改查。另外，如果时间充裕，你还可以在这个项目基础上加上自然语言交互（也就是Agent的概念），对话式查询旅游数据，这在毕业设计里属于“创新亮点”，能明显拉开与其他学生的差距。

不过也要给所有人提个醒：技术覆盖面广是一把双刃剑，它意味着你需要同时在多个方向上投入精力。如果时间管理不到位，很容易每个模块都做得浮于表面。后面我会专门聊怎么安排优先级。

2. 技术选型：每一层选择的原因和避坑逻辑

2.1 Django当后端，到底图什么

很多人一上来就问：为什么不用Flask？Flask不是更轻量、更容易上手吗？这个问题我在实际指导项目时被问过无数次。我的回答是：如果你只想要一个最简单的数据接口，Flask确实够了；但毕业设计拼的不是“够用”，而是体系完整性。

Django自带的ORM、Admin后台、用户认证、模板引擎，把这些东西都算上，你基本不用装太多第三方库就能搭起一个结构清晰的后端工程。尤其是Admin后台，这个对毕设来说真是一个大杀器——你可以把爬虫采集到的数据直接在后台里看到、修改、删除，演示的时候给评委展示一下“你看，这是后台管理界面”，评委对你的印象分立刻就不一样了。Django的项目结构和MVT模式清晰，写起来条理分明，答辩时被问到“你这个项目的架构是怎么设计的”，你也能很自信地讲清楚。

在实际使用中，我建议你这样做：用django-admin startproject travel_data_platform创建项目，再用python manage.py startapp analysis创建核心应用。你的数据模型可以放在models.py里，接口逻辑放在views.py里，用DRF（Django REST Framework）的话还可以实现标准化的RESTful API。配置数据库时，如果数据量预计在几万条以内，用默认SQLite完全可以跑得很流畅；如果准备爬几十万条数据再上机器学习，那建议换成MySQL。不过说实话，毕设场景下SQLite已经足够了，还可以省去安装数据库服务的麻烦。

2.2 Selenium爬虫：笨但有效的采集方案

爬虫选型也是一个经典问题。携程这类旅游网站的数据，很多是由JavaScript动态渲染出来的，传统用requests直接请求HTML的话，你拿到的只是一堆空壳标签，根本提取不到景点、价格、评分这些核心字段。这时候你有两个选择：一是分析它的Ajax接口，直接构造请求拿JSON数据；二是用Selenium模拟真实浏览器操作，页面渲染完成后再提取数据。

**为什么我推荐Selenium？**第一，它几乎没有分析接口的成本，对新手友好；第二，携程的接口加了不少风控逻辑，直接请求接口很容易触发验证码或IP封锁，Selenium模拟真人操作的成功率反而更高；第三，Selenium也是自动化测试领域的常用工具，你写爬虫的过程相当于顺便学习了自动化测试技术，简历上又能多一个技能点。

最经典的写法是这样的：

from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 无头模式配置 chrome_options = Options() chrome_options.add_argument("--headless") chrome_options.add_argument("--disable-blink-features=AutomationControlled") chrome_options.add_argument("--no-sandbox") chrome_options.add_argument("--disable-dev-shm-usage") driver = webdriver.Chrome(options=chrome_options) driver.get("https://you.ctrip.com/sight/beijing1.html") # 等待动态内容加载完成 wait = WebDriverWait(driver, 10) sight_list = wait.until(EC.presence_of_element_located((By.CLASS_NAME, "sightlist"))) print(sight_list.text) driver.quit()

这里有几个细节值得说明。disable-blink-features=AutomationControlled这个参数可以降低被网站识别为自动化工具的几率。等待条件绝对不能省——动态页面里元素是异步加载的，直接用find_element经常报找不到元素。你用的WebDriverWait和expected_conditions这两兄弟就是专门解决这个问题的。

2.3 机器学习如何“接地气”地用进毕设

很多人在毕设里硬加机器学习模块，结果答辩时被老师问“你的模型解决了什么实际问题”就哑口无言了。这是最典型的翻车场景。在旅游数据分析这个题目里，机器学习的应用场景其实是天然存在的，关键是选好切入点。

我建议重点考虑下面三个方向（按性价比排序）：

**第一个方向：旅游人数/价格趋势预测。**用历史月份的景点访问人数、机票价格、酒店价格数据，训练一个时间序列预测模型，预测未来一段时间的热度走势。可用算法很多，比如ARIMA、Prophet，或者用LSTM。对于毕设来说，ARIMA已经足够展示出完整的“数据集切分—训练—评估—预测”流程。

**第二个方向：景点评论情感分析。**爬取景区评论数据，用SnowNLP或基于BERT的模型对评论进行正负面情感分类，再按城市/景点聚合展示“好评率”指标。这个方向的特点是数据最容易获取、效果最直观、答辩时评委都能看懂。而且近年大语言模型很火，你还能用大模型API做进阶精调或对话式总结，把情感分析和Agent概念关联起来，创新分直接拉满。

**第三个方向：用户聚类分析。**对景点的评分、热度、门票价格等特征做K-Means聚类，把景点分成“热门高价型”“小众文艺型”“性价比型”等类别，然后在大屏上用散点图或雷达图展示各类别的特征。这个方向实现简单，适合编程能力一般的同学保底。

2.4 大模型与Agent：加分项而不是必选项

标题里有“大模型”和“agent”，说明这是近年流行的概念。但我要直说：**如果你的时间只够把爬虫和大屏做完，那大模型模块可以往后放。**毕设的核心还是工程的完整性和逻辑的严密性，新颖概念只是锦上添花。

那如果确实想做，怎么做最合理？我见过比较聪明的做法是：把大模型封装成一个“智能问数助手”。用户在大屏页面或后端接口里输入一句自然语言，比如“上个月最热门的景点是哪个”，系统调用大模型接口把问题转换成对数据库的查询语句，再把结果用自然语言回答出来。这样你的项目就有了“人工智能交互”的体验感，但又不需要从零训练模型。

Django中做接口封装时，可以用类似这样的代码组织逻辑：

# services/llm_service.py import requests import json LLM_API_URL = "https://your-llm-endpoint/v1/chat/completions" def generate_answer(question: str) -> str: """ 调用大模型接口，将问题转化为SQL查询并解释结果 """ prompt = f""" 你是一个旅游数据分析助手。用户的问题：{question} 请提取查询意图、时间和地点，返回一个JSON结构。 """ payload = { "model": "your-model", "messages": [{"role": "user", "content": prompt}], "temperature": 0.1 } resp = requests.post(LLM_API_URL, json=payload, timeout=15) data = resp.json() return data["choices"][0]["message"]["content"]

这个模块要做到“有说明、有异常处理、有示例输出”，这些内容在答辩时都能成为加分项。涉及敏感数据时，只模拟框架即可，毕设演示不需要接入真实付费API。

3. 系统设计：从数据采集到可视化大屏的完整链路

3.1 数据采集模块：携程景点数据怎么爬

整个系统的数据源是携程旅行网的景点页面，主要包括这样几类字段：

批量采集的思路是先获取目标城市列表，再逐城市进入景点列表页，翻页加载全部景点链接，最后进入每个景点的详情页提取字段。这个流程中你一定会遇到一个问题：翻页时数据是通过滚动加载的。页面滚到最底部才会加载出下一页内容。所以爬虫里必须加入模拟滚动操作，然后重新定位列表容器，避免漏抓数据。

携程这类网站对爬虫并不友好，所以实操时注意控制访问频率。我建议每抓取一次景点页面后随机休眠3到8秒，同时给浏览器设置一个随机的User-Agent和浏览窗口尺寸。虽然不能完全规避风险，但足以应付毕业设计的数据量需求。

3.2 数据清洗与入库：别让脏数据毁了大屏

数据爬下来之后，千万不能直接拖入数据库。我见过不少学生晒出的作品，大屏上的数字明显是错的——评分里有“暂无评分”这种字符串，价格字段混入了“¥145起”，评论数里有“1.2万”这种带单位的表达。这些问题不处理，图表再好看也没用。

数据清洗这一步用Pandas处理，重点做几件事：去重、格式标准化、缺失值处理、异常值过滤。价格字段先正则抽取数字再转成float；评论数字段遇到“1.2万”要乘以10000；评分为空的值直接剔除或填充分数区间的中位数（例如4.0分）。清洗后再通过Django的ORM或批量SQL脚本导入MySQL/SQLite，大屏展示的数据才可信。

3.3 数据分析指标：大屏上放什么数据才有说服力

一个大屏不是图表越多越好，关键设计原则是：每一个图表都要能回答一个业务问题。推荐的核心指标组合如下：

• 全国热门景点地图分布：地图上的点颜色和大小代表景点的热度/评分，让人一眼看到旅游资源的分布格局
• 景点评分Top10排行榜：横向条形图，直观展示头部景点
• 城市访问热度趋势：折线图，展示近几个月不同城市的搜索/访问量变化
• 评论情感分析分布：饼图或玫瑰图，装下好评、中评、差评的占比
• 门票价格区间分布：直方图，看看景区票价集中在哪个区间
• 游客画像：环形图展示年龄段、性别比例（如果爬取数据足够的话）

把这些指标摆在大屏上，整个项目的“数据分析”属性一下子就立住了。你甚至不需要额外做复杂的算法模型，光是这些统计聚合和可视化，就已经让评委觉得你在“用数据说话”。

3.4 可视化大屏布局：从原型到ECharts实现

大屏部分是整个项目最抓眼球的部分，但也是最容易做砸的部分——很多人把ECharts实例和一堆图标堆在一个页面上，结果布局混乱、间距失衡、颜色眼花缭乱。

我的建议是：动手写代码前，先用Axure、Figma或者直接在纸上画一个栅格布局原型。常见大屏布局是上下左右四区分布：顶部标题栏，左侧放排行榜和情感分析，中间放地图，右侧放趋势图和价格分布，底部放实时滚动评论列表或数据面板。这样每个图表都有明确的展示位置，版式均衡。

在ECharts实现阶段，你用pyecharts生成HTML片段再由Django模板渲染，或者直接在HTML里引入ECharts JS库写配置项都是可行的方案。前者对Python选手更友好，后者更灵活。我首推后者，因为大屏控件的联动和实时刷新都需要在前端写JavaScript逻辑，纯Python方案反而绕弯子。写完所有图表后，用CSS Grid或Flex布局拼装成一个完整的dashboard.html模板。

4. 核心环节实操：关键代码与实现细节

4.1 Selenium采集脚本的落地细节

前面已经给了基础启动代码，这里重点聊聊完整采集流程中容易出错的三个环节。

第一个是等待策略。很多新手喜欢上来就是time.sleep(5)，不管页面到底加载好没有，这样既慢又不稳定。正确的做法是使用WebDriverWait配合expected_conditions，比如明确等待某个关键元素出现或某个元素可见：

element = WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.CSS_SELECTOR, ".list-item")) )

第二个是滚动加载。携程列表页通常不是传统的分页条，而是滚动到底部自动加载。你在进入列表页后要模拟向下滚动，并且不断检测新元素数量是否增加。具体可以用driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")，然后等待两三秒，再检查列表长度，直到长度不再变化为止。

第三个是提取与去重。提取时最好用BeautifulSoup配合select_one()解析，避免Selenium自带的查找方法在复杂页面中踩嵌套坑。每个页面提取完数据后，把URL或景点名称作为唯一键放入set里做去重，同一数据不被重复抓取。把这一整套流程封装为fetch_sight_by_city(city)函数，主循环里遍历城市列表即可。

4.2 Django数据模型与接口设计

数据模型我建议设计两张核心表。一张是景点基础信息表Sight，另一张是评论表Review。如果你要做价格趋势预测，可以加第三张PriceHistory记录每日价格。模型定义示例：

# models.py from django.db import models class Sight(models.Model): name = models.CharField(max_length=100, verbose_name="景点名称") city = models.CharField(max_length=50, verbose_name="城市") rating = models.FloatField(null=True, blank=True, verbose_name="评分") comment_count = models.IntegerField(default=0, verbose_name="评论数") ticket_price = models.FloatField(null=True, blank=True, verbose_name="参考价格") address = models.CharField(max_length=200, blank=True, verbose_name="地址") play_time = models.CharField(max_length=50, blank=True, verbose_name="游玩时长") rank = models.IntegerField(null=True, blank=True, verbose_name="热度排名") class Meta: db_table = "sight" class Review(models.Model): sight = models.ForeignKey(Sight, on_delete=models.CASCADE, related_name="reviews") content = models.TextField(verbose_name="评论内容") sentiment_score = models.FloatField(default=0, verbose_name="情感得分") created_at = models.DateTimeField(auto_now_add=True)

接口部分，如果不想接DRF，直接在views.py里返回JsonResponse也行，但Django自带的序列化能力比较弱，手动构造字典比较繁琐。我建议使用DRF的ModelViewSet，三五行代码就能把上面两个模型变成一整套RESTful接口：

# serializers.py from rest_framework import serializers from .models import Sight, Review class SightSerializer(serializers.ModelSerializer): class Meta: model = Sight fields = "__all__"

主路由里注册对应的ViewSet，大屏前端直接用Ajax拉取数据。需要注意给CORS做配置，否则前后端分离开发时浏览器会拦截请求。

4.3 机器学习模型的训练与接入

以时间序列预测为例，如果你要预测某个景区未来一个月的热度，需要构造“日期-访问量/搜索量”序列。你爬到的数据里不一定有历史长序列，这里建议从一些统计网站或数据集平台补充下载历史数据，也可以将现有数据按天聚合生成。算法上用Prophet或ARIMA，核心代码如下：

# services/forecast_service.py import pandas as pd from statsmodels.tsa.arima.model import ARIMA import joblib def train_arima(df: pd.DataFrame): """ df需要包含两列: ds(日期), y(目标值) """ model = ARIMA(df["y"], order=(2, 1, 2)) model_fit = model.fit() joblib.dump(model_fit, "arima_model.pkl") return model_fit def forecast(model, steps=30): forecast_result = model.forecast(steps=steps) return forecast_result.tolist()

训练完成后保存模型文件，Django的接口里加载.pkl或joblib文件，用户请求动态调用一次即可。预测结果用折线图展示“历史趋势 + 未来预测”，这个图表放进大屏会显得整个项目高度直接提升一档。

情感分析用SnowNLP也很容易上手：

from snownlp import SnowNLP def analyze_sentiment(text: str) -> float: s = SnowNLP(text) return s.sentiments # 返回0~1之间的情感得分

把若干条评论的情感分数取平均，就得到该景区的整体好评度。由于Python库默认语料对旅游评论的适配度一般，你也可以用网上公开的酒店/景点评论语料做二次训练，把结果写进Review.sentiment_score字段。

4.4 大屏实时数据的刷新机制

大屏不能是一张静态图片，这一点一定要记住。用户（评委）的思路是：大屏数据应该是“活的”。实现“活”的方式有两种：前端轮询Django接口，或者用WebSocket推送。

前端轮询最简单，用setInterval每隔30秒或60秒调用一次接口，然后更新对应ECharts实例的setOption。这种方式写起来快，演示时也能看到效果。若要在项目里体现工程深度，就可以考虑用WebSocket或Django Channels做实时推送。前端JavaScript大致如下：

async function fetchData() { const response = await fetch('/api/sight/'); const data = await response.json(); // 更新图表 myChart.setOption({ series: [{ data: data.map(item => item.value) }] }); } setInterval(fetchData, 30000);

注意ECharts实例需要用init初始化一次，后续刷新只调setOption。很多人踩过这个坑——每次刷新都重新init，导致图表不断重绘闪烁，看起来极其业余。

5. 常见问题与避坑清单：我踩过的那些坑

5.1 爬虫阶段最容易翻车的细节

• ChromeDriver版本与浏览器版本不匹配：这是报错最频繁的问题。Selenium启动时会直接报session not created异常。解决方案是使用webdriver-manager这个库自动管理驱动版本，或者去Chrome官网下载对应版本的driver。
• 页面元素定位失败：动态网站的class名字经常是动态生成的，比如class="sightlist_2Qw3e"这种带随机后缀的样式。用绝对等于号匹配经常失败，推荐用By.CSS_SELECTOR配合模糊匹配，或者用By.XPATH基于文本内容定位。
• 验证码阻断：如果发现连续请求几十条后弹出滑块验证，说明你的访问频率太高。最有效的应对策略就是降低频率加长休眠时间，而不是升级所谓的“过验证码”手段。毕设数据量不需要那么大，慢一点完全没问题。
• 数据量不足：有些城市的热门景点只有几十个，爬下来样本量太少，大屏上的图表会很空。解决方案是扩大城市范围，比如把国内20个热门旅游城市的一级、二级景点都爬一遍，这样总数据量轻松上千。

5.2 数据处理与模型阶段容易踩的坑

清洗阶段最常见的坑是字段类型混乱。Pandas读入时，comment_count这一列可能因为混入了"暂无"而整列变成object类型，导致后续整数运算全部报错。处理办法是使用pd.to_numeric(errors="coerce")，强制转换并让非法值变成NaN，再统一填充或删除。

编码问题也值得注意。Windows下CSV默认编码是GBK，而Python读取时默认是UTF-8，直接读取中文CSV会报错。解决办法是用pd.read_csv(path, encoding="gbk")或先通过文本编辑器另存为UTF-8-BOM格式。

模型层面，时间序列预测有个巨大的坑叫数据泄漏。你在处理数据时如果不小心把未来的数据塞进了训练集里，模型在训练时性能会无比好看，但在新数据上一秒就垮掉。做时序预测，一定要严格按照时间顺序切分训练集和测试集，不能随便洗牌。拿ARIMA举例，先用前80%的时间段训练，再用后20%的时间段验证，别让模型看到未来。

5.3 Django与大屏部署阶段常见问题

开发阶段数据没问题，一到部署或换电脑演示就出问题，这是毕设项目的重灾区。第一个坑是路径写死。如果你把媒体文件或静态资源的路径用绝对路径写死在代码里（比如C:/Users/xxx/project/media），别人的电脑运行你的项目必然报错。正确的做法是使用相对路径或环境变量：

BASE_DIR = Path(__file__).resolve().parent.parent MEDIA_ROOT = os.path.join(BASE_DIR, "media")

第二个坑是依赖环境。老师演示你项目时，如果对方的电脑没有安装对应版本的Django和第三方库，项目根本跑不起来。解决办法是使用requirements.txt锁定依赖版本，最好用pipreqs根据实际导入生成一份干净列表，不要一股脑把用不到的包全装进去。更稳妥的做法是打包成Docker镜像，但那对多数学生来说又增加了一层学习成本，首选还是写好依赖清单。

第三个坑是机器学习的Java报错。如果你用PySpark或特定版本的工具包，可能会遇到JVM环境相关的报错。这类问题排查成本极高，建议毕设项目里直接避开这些组件，能跑通才是王道。系统架构上也要设计成“机器学习模型挂了也不影响大屏展示”的降级逻辑，比如用try/except捕获模型调用异常，异常时就返回一个预设的默认结果。

5.4 时间管理与答辩准备的实用建议

如果你想在三个月内稳妥完成这个项目，我的个人建议是按照下面这个节奏推进：

答辩演示前有个技巧，提前准备演示环境检查清单：确认本地服务已启动、数据库有数据、模型文件存在、大屏页面能正常读取接口。如果现场因为网络问题无法访问外部链接，提前把ECharts库和字体文件下载到本地。大部分答辩翻车都是因为技术演示时打开页面是空白，或者弹出一堆英文报错，这些在演示前完全可以通过自测避免。

答辩陈述时不要背PPT，而是拿一件真实的事情开头，比如“我爬了大概25个城市的2000个景点数据，发现目前全国旅游的热门目的地集中在这几个城市……”，用数据细节说话远比空泛的“本项目采用了Django框架”有说服力。

6. 基于个人经验的三条核心建议

做这个项目的过程中，我最大的体会是：**毕设项目不求“大而全”，但一定要“真而通”。**很多同学恨不得把爬虫、机器学习、大屏、小程序、App全部装进一个项目里，结果每一条链路都没跑通，最后演示的时候只有PPT能放。你只需要把“采集—清洗—存储—建模—展示”这条主线做扎实，就已经是一个优秀的毕业设计了。

另外，代码里多写注释不是给别人看的，是给三个月后写论文时的自己看的。很多同学写完代码不回头复盘，等到写论文时根本想不起来某个函数当时为什么这么设计。我建议每完成一个模块就顺手记录一份简单的开发日记，里面写清楚技术选型理由、实现思路、遇到的问题和解决办法。写论文时这些笔记能帮你节约至少两周时间。

最后再说一个小建议：即便毕业答辩结束了，也值得把这个项目留在你的GitHub仓库并写好README。面试的时候，能完整讲解一个“爬虫+后端+机器学习+可视化”的闭环项目，比那些只会背面试八股文的候选人要有说服力得多。这套东西做一遍，你的工程能力是真的会有一个台阶式的提升——这比最后那个分数重要得多。