旅游推荐数据分析可视化：Python从数据清洗到协同过滤看板实战

简介：面向计算机相关专业毕设学生与Python学习者的项目实战资源，基于Python+Django+MySQL实现旅游推荐数据分析与可视化，融合协同过滤算法，覆盖用户注册登录、景区浏览、评分收藏与个性化推荐，以及管理员对景区信息、类型分类、用户资料等模块的管理，可直接作为毕业设计或课程设计使用。压缩包共422个文件，约9.36MB，以174个JavaScript、59个CSS、40个JSON、27个Python源码、18个HTML页面为主，同时包含数据库SQL文件、部署说明文档及静态资源，目录结构清晰，便于按功能模块快速定位。项目经过严格调试，运行稳定，配套部署说明和数据库可帮助读者快速搭建环境并二次开发。目前已有135人学习下载，适合希望系统掌握Django项目架构、协同过滤推荐落地以及后台管理系统开发的中级学习者。

1. 旅游推荐数据分析可视化：从“脏数据”到“可汇报看板”的一次完整闭环

“python项目实战之旅游推荐数据分析可视化”这个标题，乍看像是个教程包，其实它解决的是数据分析从业者最常遇到的一类问题：给你一份旅游订单或者游记数据，里面是各种口径不一的景点名、日期、价格、评分，项目要求你既算出“这个用户下一站可能去哪”，又要把地区热度、热门景点、出行趋势画成业务方看得懂的看板。整个过程横跨数据清洗、推荐算法、接口开发和可视化，是一套不依赖企业数据平台也能完整跑通的数据分析项目。它适合正在找 python 练习项目的新手，也适合需要给业务方交付可交互看板，而不是只有 Excel 透视表的数据分析人员。

2. 先拆业务再选算法：旅游推荐可视化项目的四层结构与数据口径

2.1 一份旅游数据长什么样：先查字段，再定口径

拿到源码包第一件事，不是马上看推荐算法，而是打开数据文件。旅游推荐项目的数据通常是一张行为表，每一行代表“某个用户在某个时间去了某个景点，产生了多少消费，给了什么评价”。常见字段大概有用户 id、景点名称、所在城市、到访日期、停留时长、消费金额、评分、评论标签。如果是从公开数据源或者爬虫抓下来的，还会多一个来源 url 字段，这个字段对推荐没有直接作用，但可以用在检查数据是否重复上。

我一般会用这一段代码把字段和缺失情况打印出来，先建立数据直觉：

import pandas as pd # utf-8-sig 能兼容 Windows Excel 导出的带 BOM 中文 CSV df = pd.read_csv("data/travel_records.csv", encoding="utf-8-sig") print(df.info()) print(df.head(10))

这段代码只有两个动作，但很关键。info()会告诉你每一列有多少非空值，如果user_id缺失率很高，后面的推荐矩阵根本建不起来；head()则让你看到景点名的写法有多乱，比如“八达岭长城”可能被写成“八达岭长成”或者“八达岭长城景区”。这种不一致一般不会被报错，却是推荐结果被腰斩的最常见原因。数据口径一开始没理顺，后面所有算法和可视化都是在给错误数据化妆。

2.2 推荐算法选型：热门榜、基于内容与协同过滤怎么选

很多教程会把推荐系统讲得很重，但在这个项目里，算法选型其实就三条路。

热门榜最简单，按用户访问次数排序，适合做首页和冷启动兜底。它的问题是完全个性化，所有用户看到的结果一样，但作为“新用户没有行为数据时先丢给用户看什么”的保底方案，它永远要用。

基于内容推荐，是把景点的城市、标签、消费等级做成特征向量，然后算景点之间的相似度。它的好处是每个景点都有特征，新景点也能被推荐出去，不需要用户历史，但缺点是特征通常粗糙，城市一样不代表用户想去，效果容易偏保守。

协同过滤是这个项目最常见的核心算法。它不看景点的属性，只看“和我去过同样地方的人还去了哪里”，通过用户-景点评分矩阵计算相似度，再对候选景点做加权排序。这种做法的个性化程度最高，在有几千条行为数据时效果也最稳。

我会怎么选：数据量只有几百条时，别硬上协同过滤，用热门榜加内容相似度更稳；数据量有几千条以上时，协同过滤当主体，热门榜当冷启动兜底。再强调一句，热门榜不是用来凑数的，去掉热门兜底，新用户和新景点都拿不到任何推荐。

下表是三个方案的直观对比：

2.3 可视化选型：pyecharts 和 Flask + ECharts 怎么取舍

可视化的第一原则不是“哪个库好看”，而是“图之后放在哪里”。如果只要最后的静态截图放进汇报文档，matplotlib 就够了；如果希望拿到的是能点击、能筛选、能接后端接口的数据看板，那 matplotlib 通常不合适，因为它做交互的成本很高。

常见做法是两种。一种是 pyecharts，它把 ECharts 的能力封装成了 python 接口，适合只熟悉 pandas、不想碰前端的人，缺点是在复杂交互场景里容易被库自身的抽象卡住。另一种是 Flask + ECharts，后端用 Flask 暴露一些 JSON 接口，前端页面直接调接口渲染图表，灵活性最高，源码包里的部署说明也大多围绕这种方式展开。

我看到“源码+部署说明”这种标题，会默认数据层、算法层、服务层、展示层这四层都已经拆好。数据层负责读文件和清洗，算法层负责产出推荐列表，服务层用 Flask 把推荐结果和统计结果包成 HTTP 接口，展示层用 HTML 页面把图表画在浏览器里。后续的调参、部署、排错，全是围绕这四层在转。

3. 把源码跑起来：环境、清洗、推荐、出图的最小可复现闭环

3.1 环境准备：先按 python 安装教程装一个 3.10 虚拟环境

这类数据分析项目最怕依赖冲突。如果你还没装 Python，直接按官方 python 安装教程准备一个 3.10 的环境最省事。3.10 是比较折中的版本，pandas、numpy、scikit-learn、Flask 这几个核心依赖的兼容性都很稳。太老的 3.8 有些新语法用不了，太新的 3.12 则可能碰到某些底层库还没有对应预编译包。

我一般会在项目根目录建虚拟环境，不用全局安装：

# 创建虚拟环境 python -m venv .venv # 激活环境，Windows 用 .venv\Scripts\activate source .venv/bin/activate # 安装核心依赖 pip install "pandas>=1.5,<2.2" "numpy>=1.23,<2.0" "scikit-learn>=1.1,<1.5" flask

如果你下到的源码包自带 requirements.txt，不要跳过虚拟环境直接pip install -r requirements.txt，容易把系统环境搞乱。虚拟环境不是给新手增加操作负担，而是给你留后悔药。某一个依赖装坏了大不了删掉整个.venv目录重新建，不用动系统的 Python。安装完后用pip list看一眼版本，重点确认 scikit-learn 装上了，因为后面建用户-物品矩阵和算相似度主要靠它。

3.2 数据清洗：把“故宫”和“故宫博物院”合并成同一景点

数据清洗是旅游推荐项目里最枯燥但最值钱的部分。因为真实的数据永远不可能像教程那样规整，同一个景点在不同的表里可以有完全不同的名字。我会先把日期解析、空值删除、景点别名合并放在一个清洗脚本里，让后面所有算法和可视化都基于同一份干净数据。

import pandas as pd df = pd.read_csv("data/travel_records.csv", encoding="utf-8-sig") # 1. 日期解析，解析不了的记录直接丢弃 df["travel_date"] = pd.to_datetime(df["travel_date"], errors="coerce") df = df.dropna(subset=["user_id", "scenery_name", "travel_date"]) # 2. 去除景点名首尾空格，并把常见别名合并 alias = {"故宫博物院": "故宫", "八达岭长城景区": "八达岭长城"} df["scenery_name"] = df["scenery_name"].str.strip().replace(alias) # 3. 评分缺失时，用该用户自己的平均分填补 df["rating"] = df["rating"].fillna( df.groupby("user_id")["rating"].transform("mean") ) print(df.info()) print(df["scenery_name"].value_counts().head(20))

这里有两个参数容易踩坑。第一，errors="coerce"会让解析不了的日期变成NaT，所以后面必须搭配dropna，否则脏日期会留在表里。第二，缺失评分不要直接fillna(0)。0 在余弦相似度里会真的参与计算，把“没去过”和“很不喜欢”混为一谈是业务错误。用该用户历史评分的均值填充，含义是这个用户对景区的一般期待值，而不是“完全没得分”。

清洗到这一步，你还需要确认景点名合并后没有产生新的空值。我会用value_counts看前几个景点是否合理，如果“故宫”和“故宫博物院”仍然同时出现，说明别名映射没盖全，需要继续补词典。

3.3 协同过滤：构建 item-item 相似度，产出 Top-N 推荐

这一段是这个项目真正的核心。我这里采用 item-based 协同过滤，也就是计算景点和景点之间的相似度。当一个用户去过“故宫”并且打了高分，系统就去找和“故宫”相似的景点推荐给这个用户。相比 user-based，item-based 在物品数量小于用户数量时计算更快，结果也更容易向业务方解释。

from sklearn.metrics.pairwise import cosine_similarity import pandas as pd # 把清洗后的宽表变成用户-物品评分矩阵 matrix = df.pivot_table( index="user_id", columns="scenery_name", values="rating", ).fillna(0) # 计算景点与景点间的余弦相似度 item_sim = cosine_similarity(matrix.T.values) sim_df = pd.DataFrame(item_sim, index=matrix.columns, columns=matrix.columns) def recommend(user_id, top_n=5, min_sim=0.2): # 没有行为数据的新用户，走热门兜底 if user_id not in matrix.index: return popular_top(top_n) # 只取该用户明确打过分且大于 0 的景点 rated = matrix.loc[user_id] seen = rated[rated > 0] scores = {} for candidate in matrix.columns: if candidate in seen.index: continue score, total_w = 0.0, 0.0 for item, actual_rating in seen.items(): w = sim_df.loc[candidate, item] if w >= min_sim: score += actual_rating * w total_w += w if total_w > 0: scores[candidate] = score / total_w return pd.Series(scores).sort_values(ascending=False).head(top_n).index.tolist()

这段代码的推荐逻辑是加权平均：用户去过的景点评分越高，候选景点与这些景点的相似度越高，候选景点的推荐分就越高。最后除以total_w是为了避免“去过很多景点”的用户天然拿到更高分，这里做的是归一化。

min_sim=0.2是经验值，不是定死的。相似度低于这个阈值的候选景点会被认为“和用户去过的地方基本无关”，强行推荐只会让结果莫名其妙。top_n=5同样是业务参数，如果可视化页面设计成一行五个卡片，那 5 就是合理的；如果首页要展示瀑布流，可以考虑 10。协同过滤的代码要义不在炫技，而是让参数能通过后续调试快速调整。

3.4 Flask 接口 + ECharts：让推荐结果变成可交互看板

算法算完只是第一步，要看板能展示、让别人能点，就要用 Flask 把数据包成接口。通常我会在app.py里定义两个接口：一个推荐接口，一个趋势统计接口。前端页面通过fetch从接口拿数据，再用 ECharts 画图。

from flask import Flask, jsonify, render_template, request import pandas as pd app = Flask(__name__) # 假设前面清洗和推荐逻辑已经封装成 recommender 模块 from recommender import recommend, popular_top, df @app.route("/") def index(): return render_template("index.html") @app.route("/api/recommend") def api_recommend(): user_id = request.args.get("user_id", default="") top_n = request.args.get("top_n", default=5, type=int) result = recommend(user_id, top_n=top_n) return jsonify({"user_id": user_id, "sceneries": result}) @app.route("/api/trend") def api_trend(): trend = df.groupby(df["travel_date"].dt.to_period("M")).size().reset_index() trend.columns = ["month", "count"] trend["month"] = trend["month"].astype(str) return jsonify(trend.to_dict(orient="records")) if __name__ == "__main__": app.run(debug=False, host="0.0.0.0", port=5000)

前端页面用 ECharts 画一个横向条形图来展示推荐结果，代码结构是这样：

<!-- templates/index.html 核心片段 --> <div id="recommend" style="height: 400px;"></div> <script src="{{ url_for('static', filename='js/echarts.min.js') }}"></script> <script> async function loadRecommend(userId) { const res = await fetch("/api/recommend?user_id=" + userId + "&top_n=5"); const data = await res.json(); const chart = echarts.init(document.getElementById("recommend")); chart.setOption({ grid: { left: 100 }, xAxis: { type: "value" }, yAxis: { type: "category", inverse: true, data: data.sceneries.slice().reverse() }, series: [{ type: "bar", data: data.sceneries.map(() => 1) }] }); } </script>

这段前端代码里，slice().reverse()是为了让 ECharts 的类目轴从下往上显示，保证推荐的第一个景点出现在图表最顶端。条形图高度暂时全部设为 1，只表达“推荐顺序”。真正交付时，可以把推荐分数通过接口一起返回，让条形长度表示推荐强度，这个视觉表达更专业。

到这里，一套“读数据、清洗、算推荐、出图”的最小闭环已经跑通。你能在浏览器地址栏里访问http://127.0.0.1:5000，看到一个能响应user_id参数的项目。但跑通和跑好之间还隔着参数调优这一层。

4. 效果调优：把推荐和看板的几个参数调到能交付的状态

4.1 相似度阈值 min_sim：多少才算“有关联”

min_sim=0.2不是通用答案。不同数据集的景点相似度分布差别很大，有的数据里景区名称字段很规范，高相似度对很多，0.2 算保守；有的数据里用户行为非常稀疏，0.2 可能滤掉了几乎全部候选。

我是这样确定阈值的：先把所有非对角线的相似度拉出来看分位点，再决定阈值设在哪。

import numpy as np # 去掉每个景点和自身的相似度 sim_values = sim_df.where(~np.eye(len(sim_df), dtype=bool)).stack() print(sim_values.describe()) print("90% 分位点：", sim_values.quantile(0.9))

如果发现 90% 的相似度都低于 0.15，说明数据本身太稀疏，强行设 0.2 会让推荐列表经常凑不满top_n=5。这时有两种选择：把阈值降到 0.1，或者换算法，去用基于内容的景点标签相似度。反过来，如果 50% 的相似度都在 0.4 以上，说明用户行为高度集中，阈值可以适度抬高到 0.3，把噪声压下去。

4.2 Top-N 的 N 与热门兜底窗口：冷启动别写死

top_n不要拍脑袋写 10。要看前端页面怎么展示：一行五个卡片就写 5，瀑布流长页面可以用 9 或 12。推荐列表过长反而稀释点击意愿，业务上更看重“前几个准不准”。

真正让很多项目翻车的是热门兜底没有时间窗口。只有新用户会走热门兜底，如果热门榜直接按历史总量算，老景点会永远压在新景点前面。一个简单做法是只取最近 30 天的数据算热门：

recent_hot = ( df[df["travel_date"] >= df["travel_date"].max() - pd.Timedelta(days=30)] .groupby("scenery_name")["user_id"] .count() .sort_values(ascending=False) .head(10) )

这样新用户看到的不是“历史上最多人去过的 10 个景点”，而是“最近一个月的热门去处”，时效性和数据看板的趋势图也保持一致。

4.3 可视化大屏的交互参数：热度分级、时间滑块、地图映射

如果项目里要用可视化大屏展示地区热度，ECharts 的地图热力图是最常见的形态。核心参数是visualMap，它决定不同热度值对应什么颜色。很多新手会直接写max: 500，结果数据里某个城市访问量是 3000，其他城市全部被压成一个深色，图面完全失真。

我会先算数据的分位数，再把分位数传给visualMap.max：

# 计算热度最大值的合理上限，如 90% 分位点 import numpy as np heat_max = np.quantile(city_stats["count"].values, 0.9)

然后在 ECharts 配置里用这个heat_max。这样做的好处是，少数几个极端热点不会把整个地图的颜色层次吞掉。时间滑块则用dataZoom控制，如果只有年月趋势折线图，dataZoom的startValue和endValue可以设成数据里的最早和最晚月份，避免用户打开页面只看到一小段截图。

4.4 数据量小到矩阵稀疏：降维、兜底与内容特征

旅游推荐项目的数据量很可能只有几千条，景区却有大几十个，用户有上百个，矩阵天然稀疏。这种情况下，item-based 协同过滤经常出现“某用户没去过的所有景点相似度都接近 0”的尴尬局面。

我通常会做三件事。第一，把评分矩阵中访问量极低的景点过滤掉，比如去掉只有 1 次访问的景点，它们没有足够行为数据支撑相似度。第二，给推荐逻辑加一个“如果 Top5 不足 3 个，补齐热门榜”的兜底逻辑，宁可推荐热门，也不要让列表空着。第三，给景点表加上城市和景区标签，构建一个基于内容的相似度矩阵，当协同过滤的相似度不足时，用城市一致性作为兜底特征。

提示：这里不要一上来就引入 Spark、Redis 这类重组件。一个几千条的数据量级，pandas 加虚拟内存完全能扛住，重框架只会让部署说明复杂十倍，收益却为零。

5. 部署说明常踩的 5 个坑：现象、原因、解决

5.1 中文乱码：一打开 CSV 全是大花脸

现象：pd.read_csv读进来之后，景点名和城市全是乱码，或者开头出现一个奇怪的\ufeff字符，推荐结果里出现莫名其妙的前缀。

原因：CSV 文件是 Excel 在 Windows 环境导出的，默认带 UTF-8 BOM 头；而 pandas 默认按 UTF-8 解析，有时也会把 BOM 直接解析到第一列列名里。

解决：读取时优先用utf-8-sig，它专门处理带 BOM 的文件。如果数据源是 GBK 编码，可以加一个回退：

try: df = pd.read_csv("data/travel.csv", encoding="utf-8-sig") except UnicodeDecodeError: df = pd.read_csv("data/travel.csv", encoding="gbk")

如果你在部署说明里看到别人推荐encoding="utf-8"，那大概率只在 Linux 上生成的 CSV 里有效，Windows 数据场景一定要换成utf-8-sig。

5.2 景点名不统一：推荐结果被硬生生分成两拨

现象：推荐结果不算错，但看起来像“故宫”和“故宫博物院”是两个景点，用户去过“故宫”，系统却还在推“故宫博物院”，而且两个景点的评分被拆得很散。

原因：在 item-based 协同过滤里，不同名字的景点会被当成独立列，相似度矩阵里它们各自为政。别名没有合并，景点矩阵列数虚高，相似度也被稀释。

解决：在清洗阶段维护一份别名映射词典，把“故宫博物院”“故宫博物馆”都归并到“故宫”。同时在清洗后检查df["scenery_name"].nunique()，如果景点名数量明显多于业务认知数量，就要回头补词典。这个坑在部署后不会报错，只会在结果上慢慢体现，是最隐蔽的一种问题。

5.3 端口冲突：Flask 一启动就报 Address already in use

现象：在本地跑python app.py，终端提示OSError: [Errno 98] Address already in use，或者浏览器刷新后一直转圈。

原因：5000 端口被上一个没关干净的 Flask 进程占用，或者本机有其他程序占用了同一端口。

解决：先在命令行查占用进程，再杀掉。Linux 和 Mac 上命令是lsof -i:5000，Windows 上用netstat -ano | findstr :5000，找到进程 id 后kill。更省事的方法是直接换端口启动：

python app.py --port=5050

如果你改了app.run(port=5050)，前端调接口的地址也必须同步改，否则页面会继续请求 5000 端口。另一个排查点是debug=True，它会启动 reloader，经常让端口被两个进程同时占住，部署前务必改成debug=False。

5.4 接口正常但页面白屏：静态资源路径与字段映射错了

现象：浏览器里访问/api/recommend能正常返回 JSON，但访问首页却是白屏，或者 ECharts 图表一直不出来。

原因：前端页面的 ECharts 脚本没有加载出来，或者接口返回的字段名和前端读取的字段名对不上。比如后端返回的是sceneries，前端写成了scenery，ECharts 拿到undefined，图表自然渲染不出来。

解决：按 F12 打开浏览器开发者工具，先看 Network 面板里echarts.min.js是不是 404，再看 Console 面板里有没有TypeError。静态文件路径一定要使用 Flask 模板规则{{ url_for('static', filename='js/echarts.min.js') }}，不要手写相对路径/static/js/echarts.min.js，否则在子路径部署时一定会出问题。字段命名的问题，后端返回前先print(result)，前端收到后再console.log(data)，两头的字段对齐了再接图表。

5.5 推荐越跑越慢：相似度矩阵每次重启都在重算

现象：开发阶段几千条数据时还不明显，到几百个景点之后就发现每次启动服务要等好几分钟，点一次推荐也卡顿。

原因：相似度矩阵的计算在app.py顶层直接执行，启动一次算一次；或者没有缓存，数据量变大后矩阵计算从秒级升到分钟级。

解决：把相似度矩阵保存成 pickle 文件，启动时先读缓存。通常我放在cache/sim_df.pkl：

from pathlib import Path CACHE_PATH = Path("cache/sim_df.pkl") if CACHE_PATH.exists(): sim_df = pd.read_pickle(CACHE_PATH) else: sim_df = build_sim_matrix(df) CACHE_PATH.parent.mkdir(exist_ok=True) sim_df.to_pickle(CACHE_PATH)

注意这个缓存只在数据源不变时有效。如果你重新清洗了数据，务必手动删掉cache/sim_df.pkl，否则推荐结果会基于旧矩阵。一个常见的操作习惯是把“删除缓存”写在部署说明的更新步骤里，避免交付后业务方吐槽“改了数据没反应”。

6. 进阶：把部署说明变成能交付的数据看板，并验证推荐效果

6.1 用 waitress 代替 Flask 开发服务器

Flask 自带的app.run是开发服务器，处理并发能力有限，不适合放在生产 Linux 环境里跑。我常在部署说明里推荐用 waitress，它跨平台且不需要额外写一行代码：

pip install waitress waitress-serve --host=0.0.0.0 --port=8080 app:app

这里的app:app含义是“模块名: Flask 实例名”，也就是你在app.py里创建的app = Flask(__name__)对象。启动后，看板可以通过http://服务器IP:8080访问。如果源码包里的部署说明只写了python app.py，那它更适合本地演示，真正对外交付时还要补上 waitress 这一步才算完整。

6.2 把相似度矩阵存成 npy/pickle，让重启不重算

这个习惯能显著改善交付体验。用户第一次打开页面时请求/api/recommend，如果矩阵还要现算，体验会很差。常见做法是在启动时预加载缓存，上面第 5.5 节已经演示过读取逻辑，这里再补一个关键点：pickle 文件不要直接放在项目根目录，放到cache/目录里，并且在.gitignore里忽略它。否则别人拿到源码后，你的本地缓存连同你的环境路径一起被打包发出去，不同机器上反序列化容易出现路径相关的奇怪问题。

6.3 验证推荐效果的三个自查指标

能不能交付，不能只看图表漂亮。我每次交付前会跑三个自查指标，它们不需要线上系统也能算。

覆盖率太低说明算法被热门景点困住了，推荐列表总是那几个熟面孔。命中率太低说明推荐结果没有真正贴合用户喜好。稳定性问题通常来自代码里使用了未固定随机种子的sample()或train_test_split，如果两次推荐结果不一致，先查是否有隐式随机源。

我在交付这类数据分析项目时，最后的固定习惯是先跑覆盖率，低于 30% 就回去调min_sim，而不是急着调页面配色的细节。这样能避免很多次“看板很好看、算法实际没用”的翻车。旅游推荐这个方向，数据和场景比模型更重要，把景点归并、评分口径、冷启动兜底这三件事做扎实，推荐结果和可视化看板自然都能见人。希望帮到你。

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