开篇先说明：这是一个适合写在简历里、也适合拿去当课程设计或毕业设计的项目。我前段时间完整跑了一遍从“爬取携程网重庆市景点数据”到“可视化分析”的全流程，期间踩了不少坑，也总结出一套可以直接复用的思路。这篇文章就把整个项目的设计逻辑、代码实现、常见误区和分析结论怎么解读都讲清楚。无论你是刚开始学Python、想做数据分析练手，还是需要一份拿得出手的期末项目，都有参考价值。

1. 项目全貌：为什么选携程、选重庆、选Python

1.1 需求定位：这个项目到底在做什么

先把目标说清楚。这个项目的核心链路可以拆成四个环节：

1. 从携程网抓取重庆市景点的基础信息，包括景点名称、所在区域、评分、评论数、门票价格、热度排名等。
2. 对抓取到的数据进行清洗和结构化整理，形成一份可以直接用于分析的表格数据。
3. 使用Python的可视化库绘制图表，对景点数量分布、评分特征、评论热度、门票价格区间等进行多维度观察。
4. 结合可视化结果做业务解读，比如“重庆哪些区的景点最热门”“高评分景点是否一定高热度”“门票定价集中在什么区间”等问题。

一句话总结：用数据回答“重庆旅游景点到底呈现出什么规律”。

1.2 选型逻辑：三组关键选择背后的理由

先说说为什么选携程而不是美团、飞猪或者去哪儿。

携程的数据特征是“覆盖度高、字段规整”。景点详情页里，经纬度、所属行政区、点评数、评分、门票价格这些字段都有相对固定的DOM结构，爬取时定位元素比较方便。更重要的是，携程的大部分景点数据是服务端渲染或经过轻量接口动态加载的，比起纯前端渲染的页面更容易处理。美团的数据偏本地生活，分类混杂；飞猪的景点数据量相对有限；去哪儿虽然结构相似，但页面内的广告位和推荐位会导致数据字段不稳定。对分析型项目来说，数据源越规整，后续清洗越轻松。

再说为什么选重庆这个城市。重庆的旅游景点以“山城地形+红色文化+网红打卡”为特色，景点类型跨度很大——既有洪崖洞、磁器口这类免费开放的历史文化街区，也有武隆、仙女山这类高客单价自然景区，还有大量分布在区县的小众景点。这种差异性让数据分析更有看头：你可以在同一个城市样本里比较“类型、价格、热度、评分”之间的复杂关系。相比之下，像北京上海这种城市，景点数据量虽然大，但类型分布不够极端，分析出来的结论更“平”。

最后说为什么选Python而不是别的工具。Python在这条任务链上的优势是碾压性的：requests库处理网络请求，BeautifulSoup解析静态HTML，pandas做数据清洗，pyecharts或Plotly做交互可视化，一整套流程下来只需要装几个包，不涉及多语言切换。如果你用JavaScript写爬虫再用Tableau做可视化，中间的数据交接会平白多出很多工作。

1.3 项目执行前必须明确的边界

• 抓取频率要克制，建议每次请求间隔2到3秒，不要对着一个站点密集抓取。
• 公开数据的展示字段以展示和统计为边界，不涉及任何用户个人隐私信息。
• 建议采集总量控制在几百条量级，字段以景点名称、地址、评分、评论数、价格为主，不追求“全量”。
• 数据仅用于学习分析和可视化Demo，不与任何商业行为挂钩。

把边界先想清楚，后面写代码的时候心态会稳很多。

2. 数据采集：携程景点页面的结构拆解与爬虫实现

2.1 页面结构分析：先搞懂数据藏在哪

在写爬虫之前，我先花了不少时间在携程的景点页面上做“人工侦察”。这里有个经验：不要一上来就打开开发者工具找接口，先手动多翻几页，搞清楚数据的分页规律。

携程的景点列表页（比如重庆站）是按“热度”排序的，一页大概15个景点左右，翻页时URL里的参数会变化。这里有一个关键点：列表页本身不完整显示评论数、评分等字段的精确值，但会给出大致范围。如果只用列表页数据做分析，会很被动。

我的建议是：列表页用于“发现景点”，详情页用于“获取精确字段”。

详情页的核心信息集中在两个位置：

• 页面顶部的景点基本信息区：景点名称、评分、点评数、所属区域、门票起价；
• 简介/攻略部分：有些信息藏在无法直接渲染的卡片里，需要找到背后的XHR接口。

携程景点的详情页URL通常包含一个scenic_id或类似格式的ID，这个ID在列表页的链接里就能拿到。爬虫的主流程可以简化为：遍历列表页得到景点ID集合，再拿着ID去拼接详情页URL，逐条抓取。

2.2 请求头伪装与常见反爬应对

携程的常规反爬手段不算特别激进，但有几个细节需要处理：

第一，User-Agent不能裸奔。直接用requests默认的UA很容易被识别。我习惯在请求头里带上一整套“浏览器味”的字段，包括UA、Referer、Accept-Language，必要时再戴上Cookie（从浏览器开发者工具里复制初始请求的Cookie，大部分场景下能大幅降低触发校验的几率）。

第二，请求频率必须控制。这里可以直接用time.sleep做最朴素限速，每抓一个景点间隔2到3秒。有人说用代理池，那是大规模采集才需要的；类似这样的学习项目，带代理反而是多余的复杂度，没有必要。

第三，出现异常响应时不要硬扛。如果某个页面返回了验证码页或者跳转提示，正确的做法是记录下来，暂停几秒再重试，最多重试3次；如果还不行，就丢掉这个样本，不要影响整体进度。后面对缺失样本可以做说明性补充，数据量足够时丢掉一两个不会影响结论。

2.3 解析逻辑：BeautifulSoup定位关键字段

用BeautifulSoup做解析时，我建议用“先稳定后精确”的策略：先通过浏览器开发者工具确认目标字段所在标签的稳定特征，比如class属性，再写解析代码。不要用非常长的XPath硬匹配，页面结构一旦调整就容易崩。

下面是核心爬取逻辑的代码骨架：

python复制import requests
import time
import pandas as pd
from bs4 import BeautifulSoup

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",
    "Referer": "https://you.ctrip.com/",
    "Accept-Language": "zh-CN,zh;q=0.9"
}

def parse_scenic_detail(html):
    soup = BeautifulSoup(html, "html.parser")
    data = {}
    # 景点名称
    name_tag = soup.select_one(".cn_t")
    data["name"] = name_tag.get_text(strip=True) if name_tag else None
    # 评分（不同页面结构可能不同，以下为常见情况）
    score_tag = soup.select_one(".star a") or soup.select_one(".score")
    data["score"] = score_tag.get_text(strip=True) if score_tag else None
    # 点评数
    comment_tag = soup.select_one(".comment_count a") or soup.select_one(".count")
    data["comment_count"] = comment_tag.get_text(strip=True) if comment_tag else None
    # 地址/区域
    addr_tag = soup.select_one(".address") or soup.select_one(".detail_link a")
    data["address"] = addr_tag.get_text(strip=True) if addr_tag else None
    return data

def fetch_page(url):
    response = requests.get(url, headers=HEADERS, timeout=10)
    time.sleep(2.5)
    if response.status_code != 200:
        return None
    return response.text

这里有两个容易忽略的细节：

1. 评分和点评数在不同景点的页面上很可能不是同一套class命名。写完解析函数之后，一定要拿5到10个不同景点的页面做实测，检查字段覆盖率，再决定要不要补一套备用选择器。
2. 字符串清洗放到下一步统一做，不要在爬虫阶段处理，否则会导致爬虫代码里塞了一大堆杂乱的逻辑。

2.4 字段设计与存储：为后续分析铺路

我存储的时候用的是CSV，字段设计如下：

表格字段不建议一开始就追求大而全。分析型项目的数据采集讲究“够用就好”，字段太多反而会在清洗阶段耗费大量时间。后续如果真的需要类型字段，可以从景点名称或详情页的标签里二次提取。

3. 数据清洗：把“爬下来”变成“能分析”

3.1 文本与数值字段的清洗规则

爬下来的数据一定是不干净的。我在这个项目里遇到的典型问题，基本集中在下面几种情况：

• 评分字段是“4.5分”这种带单位的文本，需要去掉后缀转成浮点数。
• 评论数是“1.2万条点评”这种带数量级的文本，需要统一换算成整数。
• 价格字段里出现“¥45起”或“免费”字符，分别转化为数值和0。
• 地址字段包含“重庆市XX区”前缀，需要提取其中的区名作为独立列。

这些操作在pandas里实现起来很直接：

python复制import pandas as pd
import re

def clean_comment_count(value):
    if not isinstance(value, str):
        return None
    value = value.replace("条点评", "").replace("条评论", "").strip()
    if "万" in value:
        return int(float(value.replace("万", "")) * 10000)
    try:
        return int(value)
    except ValueError:
        return None

def clean_score(value):
    if not isinstance(value, str):
        return None
    nums = re.findall(r"\d+\.?\d*", value)
    if nums:
        return float(nums[0])
    return None

def clean_price(value):
    if not isinstance(value, str):
        return None
    if "免费" in value or "免票" in value:
        return 0
    nums = re.findall(r"\d+\.?\d*", value)
    if nums:
        return float(nums[0])
    return None

df["score"] = df["score"].apply(clean_score)
df["comment_count"] = df["comment_count"].apply(clean_comment_count)
df["ticket_price"] = df["ticket_price"].apply(clean_price)

df["district"] = df["address"].str.extract(r"([\u4e00-\u9fa5]{2,4}区)")

一个很容易栽的坑是：清洗函数一定要写在分析之前，并且要单独验证效果。别急着用apply一把梭，先抽样20条数据看清洗结果是否符合预期，再全量执行。否则一个正则写错，后续所有图表都会受到影响。

3.2 缺失值与异常值的处理思路

对缺失值，我的处理原则是：能补则补，不能补就丢，但要有记录。

比如某几个景点的评分字段缺失了，我查了一下可能是页面结构特殊导致的解析失败。这种可以考虑用该区域的平均分进行填补，或者直接在分析时排除评分字段为空的样本。如果要写进毕设或课程报告，建议把缺失情况单独列一小节说明，而不是默默处理掉——这种细节很加分。

异常值方面，比较典型的是评论数极高（头部景点）和价格极高（少数高端景区）并存。如果直接做线性图表，头部数据会把其他数据“压扁”。这时候通常不删除这些数据，而是在可视化时采用对数变换或分箱统计，让分布规律更直观。

3.3 构造辅助字段：让分析维度更丰富

基础字段清洗完之后，可以加两个辅助列，让后续分析更顺手：

• log_comment：评论数的自然对数，用于消除量纲差异。
• price_level：把门票价格分成免费（0元）、低价（1-50元）、中等（51-100元）、高价（100元以上）四档，用于对比不同价格带景点的热度差异。

这些辅助字段不是拍脑袋加的。在做散点图的时候，原始评论数跨度从几十到几万，直接画图会挤成一团；取对数之后点就散开了。价格分档之后，才能直观看出“免费景点是否真的更容易获得高热度”。

4. 可视化呈现：从“看得见”到“看得懂”

4.1 图表选型：每种情境对应什么图

可视化部分我用了pyecharts。选它的原因很实际：国产库、中文文档完善、生成的图表是ECharts的JavaScript文件，既可以本地HTML打开，也可以嵌入Flask或FastAPI做成Web应用，交给导师或面试官看都很方便。

下面是这个项目用到的核心图表类型及其适用场景：

选图表时最核心的判断标准就一句话：你想让读者对比什么，就选最能放大这种对比的图表。

4.2 核心维度一：重庆景点区域分布分析

第一个分析维度是区域分布。代码很简单：

python复制from pyecharts.charts import Bar
from pyecharts import options as opts

district_count = df["district"].value_counts().head(10)

bar = Bar()
bar.add_xaxis(district_count.index.tolist())
bar.add_yaxis("景点数量", district_count.values.tolist())
bar.set_global_opts(
    title_opts=opts.TitleOpts(title="重庆市各区县景点数量Top10"),
    yaxis_opts=opts.AxisOpts(name="景点数量")
)
bar.render("district_bar.html")

这个图的解读角度比较明确。渝中区、南岸区因为核心商圈和历史景点密集，通常会排在前列；而武隆、巫山这类以自然景观闻名的区县，虽然景点数量不一定很多，但单个景点的评论量和客单价往往会更高。

图表画出来以后，多往前问一步很有价值：数量分布只是表象，更值得探讨的是“数量多”和“热度高”是不是一回事。这就引出下一步——热度对比分析。

4.3 核心维度二：评分与热度的双变量分析

这个项目最有分析价值的图，是“评分-评论数”散点图。我用log_comment作为X轴，score作为Y轴，颜色映射到ticket_price：

python复制from pyecharts.charts import Scatter

scatter = Scatter()
x_data = df["log_comment"].tolist()
y_data = df["score"].tolist()
scatter.add_xaxis(x_data)
scatter.add_yaxis(
    "景点",
    [list(z) for z in zip(y_data, x_data)],
    label_opts=opts.LabelOpts(is_show=False)
)

散点图画出后的分布形态，通常能看出一个非常典型的规律：评论数高的景点，评分会集中在4.0到4.7之间，很少出现满分；评论数低的景点，评分却容易出现两个极端——要么非常接近满分（小众人少的优质景点），要么在3.5左右徘徊（体验一般的冷门景点）。这个现象解释起来也不复杂：样本量越少，评分就越容易被少数极端体验拉偏。

4.4 核心维度三：价格与口碑的关系探索

把价格离散化之后，可以做一张分组箱线图或多组柱状图，观察“不同价格带上景点的评分和评论数中位数差异”。我的经验是：

• 免费景点的评论数中位数往往更高，因为免费景点的客流量基数大，比如洪崖洞、磁器口这类地标级免费景区。
• 50元以下的中低价付费景点，评分中位值常常是最高的，因为游客对低门票的心理预期低，体验稍有亮点就容易给好评。
• 100元以上的高价景区，评分差距更大，好坏极端分化——武隆这种强IP景区评分很稳，但部分配套不成熟的区县景区就可能面临“高票价低评分”的窘境。

这里要提醒一下：相关不是因果。价格和评分之间的趋势只是“观察值”，背后还混杂了景区管理、交通便利性、游客预期等多重因素。写报告的时候，把话说成“数据显示出某种倾向”比“价格导致评分变化”要严谨得多。

4.5 仪表板组装：把图表串成完整故事

单张图看问题容易局限，把图组合在一起会好很多。我最后把所有图表整合到同一个HTML仪表板里，用Tab组件切分不同分析主题。这样交出去不是零散的HTML文件，而是一整个“重庆景点数据看板”。

组装逻辑也很简单：

python复制from pyecharts.charts import Tab

tab = Tab()
tab.add(bar, "区域分布")
tab.add(scatter, "评分热度")
tab.add(box_plot, "评分分布")
pyecharts.render("chongqing_travel_dashboard.html")

看板里还可以放两个基础指标卡：总景点数、平均评分。这样打开页面的第一眼就能获取数据全貌，再往下翻才是细分维度。整个过程下来，我强烈建议在图表标题里写“数据来源：携程网，采集时间：XXXX年XX月”——这样既规范，也避免他人对数据时效性产生误解。

5. 结论解读与常见误区：别让图表骗了你

5.1 携程平台机制带来的“数据偏差”

数据分析时最容易被忽略的，是平台自身逻辑对数据的影响。携程的景点评分有几个典型机制：

1. 点评需要用户实际消费或到访后生成，因此评论数天然偏向“已购人群”，而不是到访游客的全量。
2. 部分景点会在不同套餐价格之间拆分评价，门票、索道票、联票可能是不同链接下的点评体系，直接抓“默认详情页”只能拿到其中一个入口的数据。
3. 评分存在“惯性”，评论量很大的景点，评分变动极慢——即使近期体验下滑，存量高分评论也会把评分托住，反之亦然。

理解这些机制的意义在于：读图时不能把“评论数”直接等同于“热度”，它更准确的表达是“携程站内购买点评热度”。如果对外汇报项目，这个表述上的精确度会显得你非常专业。

5.2 平均值陷阱与分位数视角

我一开始做分析的时候直接看“各区县景点平均评分”，结果发现几乎所有区的均值都落在4.3到4.6之间，差异很不明显。后来改成箱线图看中位数和四分位距，才看清了真实差异：部分区县之所以均值漂亮，是因为有几个超高评分的小众景点拉高了整体水平，实际上大部分景点的评分中位数并不高。

所以建议：先画分布图，再做汇总统计；中位数和分位数优先于平均值。这是分析这类数据时最常见的“看不见的坑”。

5.3 从可视化到业务洞察的三步法

拿到图表后，如果只写“XX区景点数量最多”这种描述性文字，项目深度会显得不够。更完整的分析思路是三层递进：

1. 观察：图中呈现了什么现象（渝中区景点最密集）。
2. 解释：为什么会出现这种现象（渝中区历史资源集中、商圈效应、交通便利）。
3. 延展：这种现象对用户决策有什么启发（外地游客住在渝中区，游玩效率最高；本地周边游则应看向区县自然景区）。

用这个三步法把每个维度的图表都过一遍，整篇文章的深度就出来了。

6. 项目复盘：几个直接影响成败的操作细节

6.1 最耗时间的不是写代码，是字段适配

这个项目里，爬虫部分我真正写代码只用了半天，但前后适配页面结构用了接近两天。原因是不同景点的详情页存在“装修差异”——部分老页面和新页面用的字段类名不一致，导致解析结果有空缺。

我试过写“万能正则”去兼容所有页面，发现反而更脆弱。最后采用的方案是“按景点ID的数值区间来判断页面版本”，对不同版本的详情页分别定义解析函数，再在爬虫入口处做路由分发。这个思路虽然笨，但确实稳定。

6.2 尽量选稳定的关键词做选择器

BeautifulSoup的select_one用的是CSS选择器语法。写选择器时，不要用那种很长的“绝对路径”，比如body > div.container > div.main > div.box > a，不到一周页面改版就失效了。核心经验是：选一个有语义的class或id，再用它做锚点，这样容错率高很多。

6.3 数据快照意识与结果可复现

不管是小程序、毕设还是演示项目，爬虫阶段结束后，立刻把原始数据备份一份，文件名带上时间戳。这体现出项目管理的规范性，也给后续的可视化和分析阶段提供了稳定的输入——你不会因为某次页面改版，导致以前的图表全部无法重建。

6.4 关于下一步拓展的思路

如果还想在这个项目基础上继续深入，我建议保留爬虫和数据结构，把分析层做厚：

• 接入更多城市的数据，做城市间旅游热度的横向比较。
• 抓取景点近180天的评论，做文本情感分析，按好评/差评关键词生成“游客关注点画像”。
• 把仪表板部署成一个轻量Web应用，加上筛选控件，让用户自己选择查看不同区县、不同价格带的数据切片。

这些方向本质上是把“一次性数据分析”变成“持续可更新的产品”，在简历上展示的含金量会明显不一样。