基于Python的内蒙古旅游景点数据分析系统设计与实现

最近交付了一个典型的 Python 数据分析项目：基于 Python 的内蒙古旅游景点数据分析系统，源码、LW（也就是设计论文）、调试文档、配套讲解一整套都齐了。这种题在课程设计和毕业设计里出现频率极高，但它并不只是“会跑个爬虫、画两张图”那么简单。我把它从需求、技术栈、清洗、入库、可视化到文档编写的完整链路拆开讲一遍，想自己复现的人可以直接照着落地。

需要先说明一点：我做的这套项目为了流程可控，实际数据采用“模拟数据 + 少量真实公开数据”混合的方式，分析逻辑和系统架构与真实场景完全一致。如果你手头有真实数据源，替换成本很低。

1. 整体设计与思路拆解

1.1 这个系统到底解决什么问题

做任何项目，先回答一个问题：用户拿到这个系统，到底能干嘛？

旅游景点数据其实非常分散。各个在线旅游平台上有景点介绍、评分、门票、评论数量，政府公开网站上有景区等级，社交媒体上有热门推荐。普通游客想做个出行决策，得开五六个网页来回对比；景区运营人员想看周边竞品情况，也只能手动复制粘贴到 Excel 里慢慢统计。这个项目最开始的需求，就是把这些零散数据汇总到一个地方，再按照区域、类型、价格、评分、热度等维度做分析，最终用图表看板呈现出来。

所以系统目标很明确：采集或构造一批景点基础数据，清洗成标准格式，存进数据库，然后通过 Web 页面展示多维分析图表。数据量级做到几千条就足够，不需要上大数据框架，重点是流程完整、逻辑清晰。

我接触过不少同学，一上来就急着写爬虫，抓了一两个小时数据，最后做出的图表自己都解释不了。问题就出在没有提前想明白分析维度。前端展示的每一张图表，都应该能回答一个具体问题。我在需求阶段会先列问题清单，比如：

• 哪个区域的景点数量最多？
• 不同类型的景点平均评分差距有多大？
• 门票价格高低和评论热度是否相关？
• 景区评级和游客满意度有没有明显关系？
• 哪些景点评分高但评论少，属于“潜力股”？

这些问题列到需求文档里之后，后面的代码实现就不会跑偏。图表是做分析的载体，不是目的。

1.2 技术选型：为什么是 Python 全家桶

技术栈选择直接决定了开发效率。这个项目我选的是 Python 全家桶，具体每个模块用到的工具如下：

为什么不选 Django？这个系统没有用户权限、没有后台管理、没有复杂的模型关系，核心就是几个数据接口加上一个展示页面。Django 的 ORM、Admin、中间件在这个场景下全是负担。Flask 一百多行代码就能启动服务，路由写起来也直观，特别适合这种演示型项目。

可视化部分，如果你只生成静态图片，用 Matplotlib 就够。但要做 Web 看板，ECharts 的交互体验明显更好，比如图例筛选、数据缩放、鼠标悬浮提示。问题是手写 ECharts 的 option 配置对象很容易漏，pyecharts 正好把 Python 数据结构和 ECharts 配置对接起来，既保留前端渲染能力，又不用写大段 JavaScript。

1.3 系统架构分层

整体架构按照三层走：数据层、逻辑层、展示层。这个分层不是装样子，它能保证每个模块可以单独替换。

数据层负责数据来源和存储。爬虫或者模拟脚本产出原始 CSV 文件，清洗脚本对原始数据做去重、格式统一、异常过滤，之后写入 MySQL。逻辑层是 pandas 做统计分析，Flask 对外提供 JSON 接口。展示层就是 HTML 页面，通过 fetch 请求接口拿到图表配置，交给 ECharts 渲染。

分层的核心收益是故障隔离。比如网站改版导致爬虫挂了，不影响已经入库的数据展示；想换个数据库，只需要改连接函数；想让页面多一个图表，加一个接口和一个 div 就行。答辩时老师问“某个模块怎么改”，你能清楚地指出替换点，这比代码本身更能体现工程能力。

2. 核心功能模块与实现要点

2.1 数据采集：能拿现成接口就不硬爬

很多旅游页面的数据并不是写死在 HTML 里的，而是通过异步接口返回 JSON。打开浏览器开发者工具，在 Network 面板里找到返回数据的接口，直接请求它，比解析 HTML 省事得多。我一般先看接口，找不到合适的接口再写页面解析。

写爬虫时，请求头一定要带上 User-Agent 和 Accept-Language。不带 User-Agent 的请求很容易被服务器拒绝，带上真实浏览器标识一般就能正常返回。

下面是基于 requests 写的一个基础抓取模板：

import time import random import requests from bs4 import BeautifulSoup HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept-Language": "zh-CN,zh;q=0.9", } def crawl_page(url): for attempt in range(3): try: resp = requests.get(url, headers=HEADERS, timeout=10) resp.encoding = resp.apparent_encoding if resp.status_code == 200: return resp.text except requests.RequestException as e: print(f"第{attempt + 1}次请求失败: {e}") time.sleep(random.uniform(2, 5)) return None html = crawl_page("https://example.com/scenic") if html: soup = BeautifulSoup(html, "html.parser") # 按页面结构调整选择器 names = [item.get_text(strip=True) for item in soup.select(".scenic-name")]

这个模板的核心思路是“失败重试 + 随机延时”。网络请求不稳定是常态，第一次失败不代表后面都失败。随机延时则是为了不让请求频率太规律。

如果目标网站页面结构比较复杂，或者数据靠 JavaScript 动态渲染，requests 就不好使了，可以用 Selenium 控制真实浏览器抓取。但 Selenium 启动慢、内存占用高，小规模数据没必要一开始就上。我建议先用 requests 试，确认不行再换浏览器渲染方案。

这里必须多说一句：爬取任何公开数据都要遵守目标网站的规则，控制请求频率，尊重 robots 协议。项目里用小规模数据演示没问题，别拿去做大规模抓取，给自己找麻烦。

2.2 数据清洗与预处理：脏数据才是主战场

真实世界的数据从来不是规规矩矩的。价格字段可能写成“68元起”，评分可能是“4.5分”，评论数可能是“1.2万”，还有大量缺失值和重复记录。清洗阶段的核心目标就是把这些不规则的原始字段转成可分析的数值型数据。

我的清洗脚本一般按这个顺序处理：

先读数据、看数据量、看字段类型。然后用 drop_duplicates 去重，很多爬虫数据会因为翻页重复而出现同一景点多条记录。接着处理缺失值，像“名称”“区域”这种关键字段缺失的直接删掉，门票价格缺失的根据情况填充为 0，评论数缺失的填充为 0。最后是类型转换和异常过滤。

类型转换是容易报错的地方，字符串和数值混在一起的时候不能直接 astype。拿价格举例：

import re def parse_price(x): if pd.isna(x): return None numbers = re.findall(r"\d+(?:\.\d+)?", str(x)) return float(numbers[0]) if numbers else None

先用正则把所有数字提取出来，再转成 float，这样“68元起”“¥68/人”“68.0”都能统一处理。评论数如果遇到“1.2万”这种中文单位，还需要额外判断：

def parse_review_count(s): if pd.isna(s): return 0 s = str(s).strip().replace(",", "") if "万" in s: return int(float(s.replace("万", "")) * 10000) return int(float(s))

评分字段用 pandas 的 to_numeric 加 errors="coerce" 处理，非数值自动变成 NaN，后续统一过滤。这样比一个值一个值地硬解析要安全得多。

2.3 数据存储：表结构怎么设计

清洗后的数据要入数据库。我在 MySQL 里的建表语句是这样的：

CREATE TABLE scenic ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, area VARCHAR(50), type VARCHAR(50), score DECIMAL(2,1), price DECIMAL(8,1), review_count INT, play_hours INT, level VARCHAR(10), create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表的设计有个细节值得注意：score用 DECIMAL(2,1)，是因为评分一般是 0.0 到 5.0 一位小数；price用 DECIMAL(8,1)，留足了整数位和小数位；level字段存“AAAAA”“AAAA”这类等级，用 VARCHAR(10) 够用。

为什么不用 CSV 直接当存储？因为这个项目的定位是“系统”，有数据库才符合完整的软件工程流程。而且 MySQL 方便后面扩展多表关联，比如再建一张区域表、一张天气表，都可以通过外键关联。

建表时要特别注意编码，必须用 utf8mb4。如果表默认是 latin1，中文写入后全是问号，清洗做得再好也白搭。写入数据用的连接串也要指定 charset：

import pymysql conn = pymysql.connect( host="localhost", user="root", password="123456", database="tour_db", charset="utf8mb4", cursorclass=pymysql.cursors.DictCursor )

2.4 分析维度与可视化：图表要能回答问题

可视化模块是整个项目的门面。我的经验是：宁可图表少而精，也不要堆一堆无意义的图。每张图旁边配一句业务结论，会让人感觉你真的懂数据，而不是只会调库。

我在这套系统里核心做了这样几张图：

第一，各区域景点数量柱状图。一眼看出哪个区域生态资源最丰富。第二，不同类型景点的评分分布箱线图，可以看出哪个类型口碑更稳。第三，门票价格与评论数的散点图，探索“免费景区更受欢迎”还是“高门票高热度”。第四，景点类型占比饼图，展示区域旅游资源的构成。第五，热门景点 Top10 横向条形图，列出评论数最多的景点。

评分分布直方图也很实用。把评分按 0.5 分一个区间切分，看整体是偏向好评还是两极分化。这些图组合在一起，基本覆盖了一个区域旅游资源的全貌。

每个图表背后都对应一个分析场景。柱状图回答“资源分布”，箱线图回答“口碑差异”，散点图回答“价格与热度关系”，饼图回答“类型结构”。这个对应关系写进论文里，整个系统的价值立刻清晰。

3. 实操过程与核心代码实现

3.1 环境准备与目录规划

先用虚拟环境隔离依赖，避免把系统 Python 环境搞得一团糟。命令行依次执行：

python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install pandas flask pyecharts requests beautifulsoup4 pymysql openpyxl

建议使用 Python 3.9 或 3.10。pyecharts 2.x 在更高版本上我也跑过，个别传递依赖需要手动补，新手直接用 3.10 最省事。

项目目录结构我习惯这样规划：

tour-analysis/ ├─ data/ │ ├─ scenic_raw.csv │ └─ scenic_clean.csv ├─ scripts/ │ ├─ generate_data.py │ └─ clean_data.py ├─ app/ │ ├─ app.py │ ├─ templates/ │ │ └─ index.html │ └─ static/ ├─ docs/ │ ├─ 设计文档.md │ └─ 调试文档.md └─ requirements.txt

数据和代码分离，脚本和 Web 应用分离，文档单独放。这样交付的时候别人拿到目录结构就能快速定位文件，比把一堆脚本堆在根目录底下好太多。

3.2 模拟数据生成脚本

先声明一下，模拟数据不是为了造假。在这个项目里，模拟数据是用来保证开发流程不依赖外部接口的稳定性。论文里说明数据来源时写清楚“演示阶段使用模拟数据，接口数据可无缝替换”就行。

模拟数据要覆盖真实场景的多样性：区域、类型、价格、评分、评论数、游玩时长、景区等级都要有变化。条数控制在 500 到 1000 之间，太少图表没有分布感，太多清洗脚本跑起来卡。

import csv import random random.seed(2024) areas = ["东部区域", "中部区域", "西部区域"] types = ["草原景观", "沙漠景观", "湖泊湿地", "历史人文", "森林山地"] levels = ["A", "AA", "AAA", "AAAA", "AAAAA"] with open("data/scenic_raw.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["name", "area", "type", "score", "price", "review_count", "play_hours", "level"]) for i in range(800): writer.writerow([ f"景区{i:03d}", random.choice(areas), random.choice(types), round(random.uniform(3.0, 5.0), 1), random.choice([0, 0, 0, 30, 60, 90, 120, 180]), random.randint(50, 50000), random.randint(2, 12), random.choice(levels), ]) print("原始数据生成完成")

注意 csv 文件打开时要写newline=""，否则 Windows 下每两行之间会多一个空行，这个坑非常隐蔽。seed 固定下来，保证每次生成的随机数据一致，方便调试和复现。

3.3 清洗脚本 clean_data.py

清洗脚本是整套项目里性价比最高的部分。数据干净了，后面分析和图表全都顺畅。

import pandas as pd import re df = pd.read_csv("data/scenic_raw.csv", encoding="utf-8") print("原始数据量:", len(df)) # 去重 df = df.drop_duplicates(subset=["name"]).copy() # 过滤空名称 df = df[df["name"].str.strip() != ""] # 价格统一 def parse_price(x): if pd.isna(x): return None numbers = re.findall(r"\d+(?:\.\d+)?", str(x)) return float(numbers[0]) if numbers else None df["price"] = df["price"].apply(parse_price) # 评论数统一 def parse_review(x): if pd.isna(x): return 0 s = str(x).strip().replace(",", "") if "万" in s: return int(float(s.replace("万", "")) * 10000) try: return int(float(s)) except ValueError: return 0 df["review_count"] = df["review_count"].apply(parse_review) df["score"] = pd.to_numeric(df["score"], errors="coerce") # 异常过滤 df = df[(df["score"] >= 0) & (df["score"] <= 5)] df = df[df["price"].fillna(0) >= 0] df = df.dropna(subset=["name", "area", "type", "score"]).copy() # 缺失价格与评论数补 0 df["price"] = df["price"].fillna(0) df["review_count"] = df["review_count"].fillna(0) df.to_csv("data/scenic_clean.csv", index=False, encoding="utf-8-sig") print("清洗后数据量:", len(df)) print(df.head())

这里有几处必须解释一下。

drop_duplicates(subset=["name"]).copy()后面的.copy()很重要。pandas 的链式操作经常触发视图和副本的警告，加上 copy 就断了引用关系，后续赋值不会报警。pd.to_numeric(errors="coerce")是把非数值统一变成 NaN，这样后面 dropna 或者 fillna 才有意义。

导出时用encoding="utf-8-sig"而不是utf-8。原因是 Excel 打开不带 BOM 的 UTF-8 文件时会把中文识别成乱码，utf-8-sig 自带 BOM，Excel 打开就正常。这个细节在交付演示时特别管用，不然评委老师直接用 Excel 打开数据文件看到乱码，印象分直接掉。

清洗后可以做聚合统计，看整体情况：

area_stat = ( df.groupby("area") .agg( 景点数量=("name", "count"), 平均评分=("score", "mean"), 平均门票=("price", "mean"), 总评论数=("review_count", "sum"), ) .round(2) .reset_index() ) type_stat = ( df.groupby("type") .agg(景点数量=("name", "count"), 平均评分=("score", "mean")) .round(2) .reset_index() ) top10 = df.nlargest(10, "review_count")[["name", "area", "score", "review_count"]]

聚合结果建议先打印出来看一眼，确认每个分组有数据、平均数在合理范围，再去做可视化。如果聚合结果就是空表，图表渲染出来自然也是空的。

3.4 Flask 接口与 ECharts 联动

这一步是整个系统的核心展示。我用 pyecharts 生成图表配置，Flask 把配置以 JSON 形式抛给前端，前端 ECharts 负责渲染。

先看后端接口代码：

from flask import Flask, render_template import pandas as pd from pyecharts.charts import Bar, Pie, Scatter from pyecharts import options as opts app = Flask(__name__) df = pd.read_csv("data/scenic_clean.csv", encoding="utf-8-sig") @app.route("/") def index(): return render_template("index.html") @app.route("/api/area_bar") def area_bar(): data = df.groupby("area")["name"].count().sort_values(ascending=False) bar = ( Bar() .add_xaxis(data.index.tolist()) .add_yaxis("景点数量", data.values.tolist()) .set_global_opts(title_opts=opts.TitleOpts(title="各区域景点数量")) ) return bar.dump_options_with_quotes() @app.route("/api/type_pie") def type_pie(): data = df["type"].value_counts() pie = ( Pie() .add("", [list(z) for z in zip(data.index.tolist(), data.values.tolist())]) .set_global_opts(title_opts=opts.TitleOpts(title="景点类型占比")) .set_series_opts(label_opts=opts.LabelOpts(formatter="{b}: {d}%")) ) return pie.dump_options_with_quotes() if __name__ == "__main__": app.run(debug=True, port=5000)

这里最关键的是dump_options_with_quotes()。pyecharts 2.x 里这个方法会返回一段合法的 JSON 字符串，可以直接被前端解析使用。如果你用的是老版本 pyecharts，dump_options()返回的是键名不带引号的 JavaScript 对象写法，前端 fetch 后直接 JSON.parse 会报错，这是很多新手拦路的问题。

前端页面 index.html 大概长这样：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>旅游景点数据分析系统</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5.4.3/dist/echarts.min.js"></script> <style> .chart { width: 100%; height: 420px; margin-bottom: 20px; } </style> </head> <body> <h1>旅游景点数据分析看板</h1> <div id="areaBar" class="chart"></div> <div id="typePie" class="chart"></div> <script> function loadChart(containerId, apiPath) { fetch(apiPath) .then(r => r.json()) .then(option => { const chart = echarts.init(document.getElementById(containerId)); chart.setOption(option); }); } loadChart('areaBar', '/api/area_bar'); loadChart('typePie', '/api/type_pie'); </script> </body> </html>

写前端时要注意给图表容器明确的高度。很多初学者遇到“图表不显示”的问题，原因不是代码逻辑错了，而是 div 高度默认为 0，ECharts 压根没有渲染空间。CSS 里写了.chart { height: 420px; }之后，问题立刻消失。

3.5 论文、调试文档与讲解的配套

这类交付项目通常不只是要代码，LW、调试文档、讲解都要有。这些材料不是随便凑文字的，它们直接决定了项目最终的评价。

LW 也就是设计论文，我一般按这个结构组织：摘要和关键词、绪论（背景、意义、国内外现状）、需求分析（功能需求、数据需求）、总体设计（架构、功能模块）、详细设计与实现（每个模块的流程图、表结构、核心代码）、系统测试（测试用例、结果）、总结。写“详细设计”时把上面这些清洗逻辑和接口设计放进去，再用一两张截图展示效果，篇幅自然够了。

调试文档要面向“第一次拿到代码的人”。环境准备、虚拟环境创建、依赖安装、数据库建表、启动 Flask、访问地址，每一步都要写到。最好把 Windows 和 macOS 两套命令都放进去，这样不管老师用什么系统都能跑起来。我见过太多项目代码本身没毛病，但环境依赖没写清楚，换台机器直接报废。

讲解部分我习惯做 5 到 10 分钟的演示脚本：先讲背景和解决的问题，再启动系统展示图表，最后打开代码讲清洗和接口两个核心模块。讲的时候多强调“为什么这样设计”，少念代码，效果会好很多。

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

4.1 中文乱码（出现频率最高）

中文乱码是这类项目里最常见的问题，没有之一。它可能出现在以下几个环节：

排查乱码的正确思路是先确认数据在哪一步变坏的。你可以先打印原始 CSV 的读入结果，再查数据库里的值，最后看页面显示。从数据流上游往下游定位，很快能找到断点。不要一上来就怀疑 pandas，很多时候是文件本身编码就错了。

4.2 类型转换报错

把“68元起”直接 float() 肯定报 ValueError，把“4.5分”直接 astype(float) 也会挂。核心解决思路是：先统一格式，再做类型转换。价格和评分用正则提取数字，评论数单独处理“万”单位，全部转成纯数值再交给 pandas。

另外一个隐蔽问题是评分字段里可能有空字符串。空字符串 to_numeric 后变成 NaN，NaN 参与比较会出现奇怪结果，比如NaN > 5也是 False，导致过滤条件不起作用。所以一定要先用dropna(subset=["score"])把缺失评分删掉，再做区间过滤。

4.3 pyecharts 图表不显示

图表不显示的时候，先按顺序检查这几样：

• 容器有没有高度。ECharts 初始化时如果容器高度为 0，不会渲染任何内容。给 div 一个显式 height 即可。
• 接口返回是不是合法 JSON。直接浏览器访问/api/area_bar看返回内容。pyecharts 老版本dump_options()返回的不是严格 JSON，需要换成dump_options_with_quotes()。
• 前端的 fetch 路径对不对。检查 Flask 路由和请求地址是否匹配，端口是否一致。
• 数据源是不是空的。清洗后如果字段全是 NaN，groupby 结果就是空，图表自然空白。

我调试的时候习惯先手动访问接口，确认 JSON 结构没问题后再看前端。这样能把后端问题隔离掉，不用来回猜。

4.4 Flask 启动相关问题

端口被占用是最常遇到的启动问题。默认 5000 被别的程序占了，Flask 会直接报错退出。改端口一行代码：app.run(debug=True, port=5001)。

还有一种情况是浏览器访问127.0.0.1:5000提示拒绝连接，但终端没看到报错。这种情况大多是虚拟环境没激活，或者 Flask 进程根本没起来。看终端有没有输出“Running on http://127.0.0.1:5000”这句话，没有就说明服务没启动成功。

修改了代码但页面没变化，先确认debug=True没写错。debug 模式下 Flask 会监听文件变化自动重启，但还是偶发不生效，最稳妥的方法是手动重启一遍进程。

4.5 数据清洗相关的坑

清洗阶段有个问题很普遍：清洗脚本会重复执行，每次都从头读原始 CSV，如果原始文件发生变化，结果也跟着变。我的做法是清洗脚本只做到“原始 CSV → 清洗后 CSV”这一步，后面所有分析和接口都读清洗后的scenic_clean.csv，不要每次都重新清洗。这样处理链路清晰，也不容易出现不同阶段的同学对着不同数据版本争论的情况。

另一个建议是清洗脚本里多打印中间结果。比如每处理完一个字段，print 一下这一列的非空值数量。这能帮你快速发现某个字段是不是全被清空了，而不是等图表空了我才回头查。

5. 做完这个项目后的一些体会

5.1 数据质量决定分析上限

整套系统跑通之后我最大的感触是：图表只是最后那一下的呈现，真正花时间的是数据清洗。清洗脚本看似不起眼，但它的质量直接决定了后续所有分析的可靠性。数据里全是脏值，后面用再炫的图表也救不回来，只能得出错误的结论。所以我在交付这类项目时，会特意把清洗脚本写得更细致，也比其它模块花更多时间验证输出。

5.2 演示型项目一定要“可解释”

做给外人看的系统，每个图表旁边最好有一句业务结论，比如“西部区域景点数量最多，但平均评分低于中部区域”。这句话不是多余的装饰，它会让看的人快速理解你为什么要放这张图。答辩时老师问“这个柱状图有什么意义”，你能说出背后的业务洞察，比单纯讲“我用 pandas 的 groupby 统计了一下”要加分得多。

5.3 这套系统还能往哪扩展

从扩展性来看，这个项目还有不少可以继续玩的方向。加上时间维度可以做每个季度的热度趋势；接入天气数据可以分析天气和客流的关系；把评论内容抓下来做情感分析，能挖掘游客满意度背后的原因；甚至用线性回归试试用门票价格、景区等级这些特征预测评论热度。这些方向都可以作为论文里的“未来展望”，也让项目在深度上更有延展空间。

我在实际操作中体会最深的一点是：这类数据分析系统真正难的不是某个单一技术点，而是把爬虫、清洗、存储、分析、可视化、文档编写这条链路完整打通。每个环节单独看都不难，连起来之后才真正考验整体把控能力。如果你正在做同类的项目，别急着写代码，先把数据字段、分析维度和目录结构想清楚，后面会顺很多。