Python爬虫实战：影视评分数据采集与观众偏好分析

从三年前第一次接触 Python 爬虫，到后来靠它做过竞品数据采集、行业信息聚合，再到最近这段时间花了两周做完影视剧评分统计与观众偏好分析，我一直觉得爬虫最迷人的地方不是“能把网页数据抠下来”这个动作本身，而是它把散落在互联网各处的信息，变成一张可以观察、可以提问、可以验证判断的数据表。这次的项目也一样：目标很简单，就是把某几家主流影视平台上的评分、评论人数、剧集年份、类型标签这些公开信息抓下来，统计评分分布规律，再结合观众的评分行为去看偏好趋势。这篇文章我会把完整过程拆开讲，包括每一步为什么这么设计、代码怎么写、运行中会遇到哪些真实问题，以及最后从数据里看出了什么。

先说说我为什么要做这个项目，以及整个项目的边界是怎么定的。如果你也想拿爬虫练手又不想做“为了爬而爬”的玩具，这篇应该能给你一个比较完整的参考系。

1. 项目源起与方案选择：评分数据到底能回答什么问题

影视剧评分数据有意思的地方在于，它既是内容质量的一个映射，也是观众群体审美偏好的投影。《狂飙》9分和《三体》8.7分之间差的不只是制作水平，还有受众结构、观看场景、话题传播度的差异。所以我想做的不只是“把评分抓下来画个图”，而是希望通过评分和观众行为数据，回答几个问题：

• 近几年高分国产剧有什么共同特征？是题材，是集数，还是播出年份？
• 高分不等于高热度，那评分和评论人数之间的关系到底长什么样？
• 观众的评分习惯是否在变化？比如是不是越来越两极分化，或者“补分”现象更明显了？
• 不同剧集类型之间的评分分布差异有多大，这种差异稳定吗？

带着这些问题，我对方案做了几轮取舍，最终圈定下来这样的设计：

技术栈上，抓取用 requests + BeautifulSoup，数据清洗和分析用 pandas，可视化用 matplotlib 和 seaborn。没有用 Scrapy，因为项目规模不大，单机脚本足够满足需求，而且这套组合对新手最友好，调试也直观。如果你想上规模，后续迁移到 Scrapy 或者用 aiohttp 做异步抓取也很容易，但第一版没必要给自己加复杂度。

数据源上，我选了国内几个公开的影视资料站，包括主流的评分平台和视频网站的剧集介绍页。注意这里没有碰任何需要登录或者付费的内容，全部是公开可访问的静态页面字段。抓取范围圈定为2015年至2025年之间播出的国产电视剧和网剧，限定在“剧集”而非“电影”，原因是剧集的评分人数和评论行为比电影更能反映长尾偏好的累积变化。

抓取字段上，每部剧记录这六项：剧名、首播年份、剧集类型、集数、评分、评分人数。后来我在此基础上又加了一个字段——短评样本，用来做简单的评论文本分词，当作偏好分析的补充信号。不过短评的抓取量比较大，对反爬压力也比较高，所以我设置了最多抓取每部剧前200条短评的阈值。这个量级用于观察情绪倾向已经足够了，后面会详细讲。

这个方案的核心逻辑是：数据量不需要覆盖全量，但字段结构要对，样本分布要足够广。不是所有影视剧都有必要抓，评分人数低于一千的样本我不收录，因为它们统计意义太弱，拉进分析里只会制造噪音。

2. 环境准备与目标页面的结构分析

2.1 Python 环境与依赖安装

Windows 上我建议直接装 Python 3.10 以上的官方安装包，一定要勾选“Add Python to PATH”。这一步很多人忽略，导致后面命令行里敲 python 没反应。装完验证一下：

bash复制python --version

如果输出 3.x 就没问题。接着安装项目依赖，注意我用了国内镜像加速，否则 uv 或者 pip 会慢到怀疑人生：

bash复制pip install requests beautifulsoup4 pandas matplotlib seaborn lxml -i https://pypi.tuna.tsinghua.edu.cn/simple

requests 负责发 HTTP 请求，beautifulsoup4 负责解析 HTML，lxml 是比默认 html.parser 更快更稳的解析引擎，pandas 做数据框操作，matplotlib 和 seaborn 最后画图。这套组合装好后基本不用再补充什么。

如果你平时用 VSCode 而不是 IDE，建议找一个解释器路径选到刚才装的 Python，否则 F5 调试会指向其他环境，报一些莫名其妙的模块缺失错误。这个坑我踩过好几次，不是代码问题，是解释器选错了。

2.2 分析目标页面的 HTML 结构

拿到页面之后不要立刻写代码。先打开浏览器开发者工具（F12），切到 Elements 面板，定位评分数字所在的节点。这里有一个很实用的技巧：在 Elements 面板里按 Ctrl+F，直接搜索 score 或者评分相关的高亮关键词，能帮你快速找到目标数据的挂载位置。

我以某个资料站的剧集列表页为例，它的结构大概是这样的：

html复制<div class="movie-item" data-id="12345">
  <span class="title">漫长的季节</span>
  <span class="year">2023</span>
  <span class="type">剧情 / 家庭 / 犯罪</span>
  <span class="episodes">12</span>
  <span class="score">9.4</span>
  <span class="votes">686342</span>
</div>

用 BeautifulSoup 抓取的时候，最稳定的方式是按 class 定位再取文本。但要注意：有些站点的数据不是纯静态的，而是通过 XHR 接口返回 JSON。如果你发现 Elements 面板能看到数据，但直接拿 requests.get 却抓不到，说明页面是动态渲染的，这时候你有两条路：一是找页面底部的 <script> 标签里有没有 window.__INITIAL_STATE__ 之类的初始数据，二是直接用浏览器开发者工具的 Network 面板，筛选 XHR 请求，找到真正返回 JSON 的那个接口，直接请求它。

我在这个项目里两个方案都用了。列表页走静态 HTML 解析，短评数据走 XHR 接口。这样做的好处是短评接口返回的 JSON 结构非常干净，几乎不用做数据清洗。

2.3 字段设计与存储结构规划

在写爬虫之前，我先把最终要落库的表结构定义清楚。这比想象中重要，因为爬虫跑起来以后数据是批量的，如果字段名前后不一致，清洗阶段要花大量时间对齐。我的表结构设计为：

存储上我选了 CSV 而不是 Excel，原因是 pandas 对 CSV 的读写更快，文件也更透明，中途断了可以直接看已抓到多少数据。如果数据量特别大，后续迁移到 SQLite 也很容易，只需要 df.to_sql('drama', sqlite3.connect('drama.db')) 一行。

3. 爬虫核心实现：从单页抓取到批量抓取

3.1 基础请求与异常兜底

写爬虫的第一件事不是解析数据，而是把请求封装得足够健壮。我见过太多同学直接用 requests.get(url) 一把梭，结果网站稍微慢一点就报 connection error，程序直接崩。正确的做法是把请求封装成一个函数，加超时、重试、UA 伪装和简单的限速逻辑：

python复制import requests
import time
import random

def safe_get(url, session, retries=3, timeout=10):
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
        "Accept-Language": "zh-CN,zh;q=0.9",
        "Accept": "text/html,application/xhtml+xml"
    }
    for attempt in range(retries):
        try:
            resp = session.get(url, headers=headers, timeout=timeout)
            if resp.status_code == 200:
                return resp
            else:
                print(f"HTTP {resp.status_code}: {url}")
        except requests.RequestException as e:
            print(f"请求异常: {e}, 第{attempt + 1}次重试")
            time.sleep(2 ** attempt)
    return None

这里有几个细节值得说：retries 用指数退避的方式递增等待时间，第一次失败等 2 秒，第二次等 4 秒，避免失败后立刻高频重试把对方服务器惹毛。session 对象复用连接池，比每次单独发请求节省大量握手开销。UA 伪装只是为了让服务器觉得这是正常的浏览器访问，不是机器脚本，属于基本礼仪。

请求间隔我也做了随机化，time.sleep(random.uniform(1, 3))，这样不会形成稳定的访问频率，对服务器更友好，也有助于避免 IP 被临时限制。别小看这个随机间隔，实际跑下来能把请求成功率高几个百分点。

3.2 列表页解析与数据提取

拿到页面 HTML 之后，用 BeautifulSoup 解析并提取字段。这里的关键是写选择器时要基于稳定的 class 名，而不是浏览器的当前位置。比如不要依赖 #content > div:nth-child(3) > span 这种很脆的路径，因为页面只要有细微改版，这个路径就全废了。

我更推荐“先定位条目容器，再在容器内提取字段”的思路：

python复制from bs4 import BeautifulSoup

def parse_list_html(html):
    soup = BeautifulSoup(html, "lxml")
    items = []
    for block in soup.select("div.movie-item"):
        title_el = block.select_one(".title")
        year_el = block.select_one(".year")
        score_el = block.select_one(".score")
        votes_el = block.select_one(".votes")
        if not all([title_el, score_el]):
            continue  # 缺核心字段，跳过
        title = title_el.get_text(strip=True)
        year = int(year_el.get_text(strip=True)) if year_el else 0
        score = float(score_el.get_text(strip=True))
        votes_raw = votes_el.get_text(strip=True)
        votes = int(votes_raw.replace(",", "").replace("人评分", ""))
        items.append({
            "title": title,
            "year": year,
            "score": score,
            "votes": votes
        })
    return items

这里 select_one 如果找不到元素会返回 None，所以判断一下再取文本，避免 NoneType 报错。这也是爬虫代码最常见的崩溃原因之一，页面结构稍微一变，选择器扑了个空，整个循环就停了。防御性写法不是可有可无的。

如果你发现 get_text() 返回的字符串里有 \n、空格或“人评分”这类干扰文本，不要手忙脚乱去正则匹配，直接链式调用 strip() 和 replace() 清理即可。先转成干净的数字再做类型转换，这是最省事的路线。

3.3 短评接口的 JSON 解析

短评这个需求比较特殊，因为它不在列表页里，需要进入剧集详情页才能拉取。我通过开发者工具观察到的接口大概长这样：

text复制https://api.example.com/drama/12345/comments?limit=200

返回 JSON 的结构是：

json复制{
  "comments": [
    {"text": "画面太美了，每个镜头都像壁纸", "rating": 5},
    {"text": "节奏有点慢，但后面渐入佳境", "rating": 4}
  ]
}

解析这种接口就是直接用 resp.json() 取字段，不需要 BeautifulSoup 了。我建议把短评抽取单独写一个函数：

python复制def fetch_comments(session, drama_id, detail_url):
    api_url = f"https://api.example.com/drama/{drama_id}/comments?limit=200"
    resp = safe_get(api_url, session)
    if not resp:
        return []
    try:
        data = resp.json()
    except ValueError:
        return []
    comments = [item["text"] for item in data.get("comments", [])]
    return comments

有些接口会做频率限制，连续请求太快会返回 429 状态码。我在真实抓取中就遇到过，最稳妥的办法是每抓一部剧的短评之后，time.sleep(random.uniform(2, 4))。短评属于详情数据，不是列表页那种批量数据，没必要催得太紧。

另一方面，短评接口给的是全部评论吗？不一定。我看到的接口默认是按“热度”排序的，你拿到的 200 条更偏向热门评论，不代表全体观众的随机抽样。在分析阶段要记住这个偏差，后面我会专门讲怎么处理这种“样本有偏”。

4. 翻页、数据持久化与进度管理

4.1 自动翻页逻辑

列表数据通常不止一页，翻页逻辑最常见的错误是手动改 URL 参数时没有注意边界条件。有的网站第一页 URL 不带页码参数，第二页才开始带 ?page=2；有的网站用 POST 请求翻页，体面一点的实现其实都是 GET。我在这个项目里遇到的翻页方式是 ?page=1 直到 ?page=50 这种递增式，比较简单。

写翻页代码时要做一个终止条件，否则程序会一直请求下去，浪费流量还可能触发安全策略。常见的终止条件有两种：一种是解析后 items 为空，说明已经翻到最后一页；另一种是当前页出现的剧名和历史页重复，说明页面可能在循环跳转。我两个判断都加上了：

python复制max_pages = 100
all_items = []
for page in range(1, max_pages + 1):
    url = f"https://example.com/drama/list?page={page}"
    resp = safe_get(url, session)
    if not resp:
        break
    items = parse_list_html(resp.text)
    if not items:
        print(f"第{page}页为空，停止翻页")
        break
    all_items.extend(items)
    print(f"已抓取第{page}页，累计{len(all_items)}条")
    time.sleep(random.uniform(1, 2))

这里 max_pages = 100 是个保险杠，防止异常情况下无限循环。真实项目里如果明确知道自己要抓多少类目多少页，可以直接写成循环到某个固定页数，但终止判断一定要保留。

4.2 CSV 持久化与断点续抓

爬虫跑到一半断掉是常态，可能是网络抖动，可能是被限流，也可能只是电脑休眠了。如果每次都是从零开始抓，既浪费时间也浪费对方服务器的资源。我的做法是每抓完一页就增量写入 CSV，而不是全部跑完再写：

python复制import csv

def append_to_csv(rows, filepath="drama_raw.csv"):
    file_exists = False
    try:
        with open(filepath, "r", encoding="utf-8") as f:
            file_exists = True
    except FileNotFoundError:
        pass

    with open(filepath, "a", newline="", encoding="utf-8-sig") as f:
        writer = csv.DictWriter(f, fieldnames=["title", "year", "genre", "episodes", "score", "votes", "comment_samples"])
        if not file_exists:
            writer.writeheader()
        writer.writerows(rows)

这里编码用了 utf-8-sig，为什么？因为带 BOM 的 CSV 用 Excel 打开不会乱码，中文数据这个细节特别重要。如果你用 utf-8 纯编码，pandas 能正常读，但很多人拿到手会直接用 Excel 打开，那个乱码会让人以为数据坏了。

增量写入还有一个好处：可以随时 Ctrl+C 停止程序，然后从上次的位置继续跑。断点续抓我实现得比较简单，就是启动时读取已有的 CSV，把已经抓到的剧名放进一个集合，在翻页循环里跳过已经在集合里的条目：

python复制import os
already_seen = set()
if os.path.exists("drama_raw.csv"):
    df_existing = pd.read_csv("drama_raw.csv", dtype={"title": str})
    already_seen = set(df_existing["title"].tolist())

for item in items:
    if item["title"] in already_seen:
        continue
    # 处理新数据

4.3 多页并发与线程池的取舍

很多人看到数据量大就想上多线程。我用 ThreadPoolExecutor 做过一次小规模测试，把单线程的请求时间从 30 分钟压到 8 分钟。但我不建议新手第一版就上并发，原因很简单：并发请求带来的不仅仅是速度提升，还可能是被封风险翻倍、程序报错更难排查、翻页顺序错乱导致数据分析出错。

如果你的目标只是几千条数据，单线程加上合理的随机等待就已经够了。如果目标是几万条以上，可以考虑用 ThreadPoolExecutor(max_workers=4)，但每个线程内部也必须保持 sleep，避免瞬时请求量暴增。

python复制from concurrent.futures import ThreadPoolExecutor, as_completed

def fetch_one(page):
    url = f"https://example.com/drama/list?page={page}"
    resp = safe_get(url, session)
    if not resp:
        return []
    items = parse_list_html(resp.text)
    time.sleep(random.uniform(1, 2))
    return items

with ThreadPoolExecutor(max_workers=4) as pool:
    futures = [pool.submit(fetch_one, p) for p in range(1, 51)]
    for future in as_completed(futures):
        page_items = future.result()
        append_to_csv(page_items)

道理虽然简单，但我还是想多说一句：效率不是爬虫的第一目标，稳定才是。数据抓不全，速度再快也没用。

5. 数据清洗与评分统计：从粗糙数据到可靠指标

5.1 原始数据的脏数据处理

爬完的数据不可能是干净的。我遇到的问题有这几类，估计你也会遇到：

• 年份字段混入了“2023-02-18”这种完整日期，需要截取前四位
• 集数有的是“12集全”，有的是“更新至20集”，需要去掉中文再转 int
• 评分字段有时会出现“暂无评分”的占位文本，直接 float() 会抛异常
• 评分人数有的带“万”单位，比如“68.1万”，需要换算成 681000

这些问题在 pandas 里都能比较优雅地解决。我写了一个清洗函数的片段：

python复制import pandas as pd
import re

def clean_votes(value):
    if isinstance(value, str):
        if "万" in value:
            return int(float(value.replace("万", "")) * 10000)
        value = value.replace(",", "").replace("人评分", "")
    try:
        return int(value)
    except (ValueError, TypeError):
        return None

def clean_year(value):
    match = re.search(r"(19|20)\d{2}", str(value))
    return int(match.group()) if match else None

def clean_episodes(value):
    text = str(value).replace("全", "").replace("集", "").replace("更新至", "")
    text = re.sub(r"\D", "", text)
    return int(text) if text else None

这几段代码很基础，但清洗逻辑一定要放在“数据入库后、分析前”这个阶段，不要指望抓的时候就能拿到完美数据。网页上的文本天然就有噪声，把清洗作为一个独立步骤会让项目结构清晰很多。

清洗后的数据要去掉核心字段缺失的行。我的筛选条件是：score、year、votes 三个字段都非空才保留，否则直接丢弃：

python复制df.dropna(subset=["score", "year", "votes"], inplace=True)
df = df[df["votes"] >= 1000].reset_index(drop=True)

评分人数低于 1000 的剧样本量太小，留着只会给统计增加噪声。这是我做数据分析时一贯的原则：宁可牺牲一点样本量，也要保证数据质量。

5.2 评分的整体分布与描述性统计

清洗后的数据，第一件事是先看整体分布。我用的代码：

python复制import matplotlib.pyplot as plt

plt.rcParams["font.sans-serif"] = ["SimHei"]
plt.rcParams["axes.unicode_minus"] = False

fig, axes = plt.subplots(1, 2, figsize=(14, 5))

axes[0].hist(df["score"], bins=np.arange(2, 10.5, 0.5), edgecolor="white")
axes[0].set_title("评分分布直方图")
axes[0].set_xlabel("评分")
axes[0].set_ylabel("剧集数量")

axes[1].boxplot(df["score"], vert=False)
axes[1].set_title("评分箱线图")

plt.tight_layout()
plt.show()

这里特别提醒一个细节：plt.rcParams["font.sans-serif"] = ["SimHei"] 这行必须加上，否则 matplotlib 画中文标题时会被框框或者乱码替代。如果你用的是 Mac，字体名应该换成 ["Arial Unicode MS"]，Windows 上 SimHei 没问题。

从描述性统计来看，我清洗后的样本里评分均值大概是 7.82，中位数 7.9，标准差 0.84，呈现明显的左偏分布。直观理解是：大部分剧集集中在 7 到 8.5 分这个区间，8.5 以上开始明显变少，9 分以上凤毛麟角。这和“大部分剧都是平庸的，好剧是少数”的直觉是一致的。

更有意思的是结构分布。我按年份分组算均值：

python复制year_score = df.groupby("year")["score"].agg(["mean", "median", "count"]).reset_index()

这里我建议同时输出均值和样本量，因为某些年份的好剧多、评分均值高，但样本量可能很少，代表性不够。看数据的时候容易被均值骗了，要结合样本量来看。

5.3 评分与评分人数的关系

评分的另一个重要维度是热度，这里用评分人数代偿。评分人数不直接等于播放量，但它是一个比较可靠的“公共讨论热度”代理指标。

我画了一张散点图看“分值和热度”的关系：

python复制plt.scatter(df["score"], np.log10(df["votes"]), alpha=0.4)
plt.xlabel("评分")
plt.ylabel("评分人数(log10)")

这里用 log10 做纵坐标缩放，是因为评分人数从一千到几十万跨越了三个数量级，不取对数的话散点图会被几个高分爆款给“压扁”，完全看不出分布形状。

分析下来我发现两个现象，挺有意思：

一是评分极高（9分以上）和评分中上（8.0-8.8）的剧，热度都很高。说明“口碑”和“热度”在这个区间是互相强化的。9分以上的剧不一定人人喜欢，但至少足够多人看过并参与评价，才可能把分数推到顶。

二是低分区（5-6分）也存在一批高分人数样本，这类剧往往是被全网吐槽带火的“烂剧”，大家打低分打得理直气壮。这种分布说明评分人数反映的是关注度而不是喜欢程度。

6. 观众偏好分析：时间线、题材与评分的隐藏关联

6.1 按年份观察评分中枢与评分情绪的迁移

把数据按年份切开来观察，能看到一些有信息量的变化趋势。我用 pivot_table 做了一张年份·评分区间的人数热力表：

python复制df["score_bin"] = pd.cut(df["score"], bins=[0, 6, 7, 8, 9, 10], labels=["0-6", "6-7", "7-8", "8-9", "9-10"])
pivot = pd.pivot_table(df, index="year", columns="score_bin", values="title", aggfunc="count", fill_value=0)

从表里的趋势看，2015年那会儿高分剧占当年剧集的比例在 10% 左右，到了2020年之后，7-8分这个区间的占比显著变大，8分以上的剧也多了。这个现象解释起来很复杂，但一个比较可信的假设是：剧集市场在向“精品化”调整，投资方更愿意集中资源做少数几部剧，而不是广撒网。另一个信号是观众对“平庸剧”的耐心在下降，6分以下的剧占比并没有显著下降，说明烂剧依然存在，但它们的关注度在下降。

再叠加一个“评分人数”的中位数变化，能看到观众参与评价的意愿整体在提升。2015年的爆款剧可能只有两三万人打分，而2023年的现象级剧往往有七八万人甚至更多打分。这背后反映的是评分文化的成熟，也是内容分发从“人找剧”变成了“剧找人”。

6.2 题材维度的评分偏好差异

类型标签是我比较看重的字段，因为它直接对应“偏好”。我用分隔符 / 把 genre 字段拆开，然后对每个类型单独统计评分均值和评分人数中位数：

python复制genre_list = []
for types in df["genre"].astype(str).str.split("/"):
    for t in types:
        genre_list.append({"genre": t.strip(), "score": ...})

这里要注意拆分后同一个样本会同时出现在多个类型里，所以做“类型评分均值”时是重复计数的，不代表独立样本。比如一部“剧情 / 悬疑”剧，它的评分会同时拉进剧情类和悬疑类的均值计算。但就偏好分析而言，这个重复计数反而合理，因为我们关心的不是“类型之间是否独立”，而是“属于某个类型的剧整体质量水位是多少”。

统计结果里比较显著的是：悬疑、犯罪、历史三类剧的评分均值都在 8.2 以上，明显高于爱情、喜剧类型。一个可能的解释是这些类型更容易出一个强情节的故事框架，观众打高分更集中；而爱情和喜剧因为受众期待分散、催更压力大，容易走向套路化，评分自然被拉低。

但要注意，类型均值高不代表“观众最喜欢”。把“评分均值”和“评分人数均值”放在一起看，你会看到另一个信号：喜剧和爱情类的评分人数均值明显偏高，说明它们的受众基数更大，只是情绪更分散。逗人笑的剧口碑上限也许没那么高，但受众覆盖面广，话题传播能力强。

6.3 集数短与评分高之间的微弱正相关

我跑了一个简单的相关系数矩阵，发现 episodes 和 score 的 Pearson 相关系数大约是 -0.28，说明集数和评分之间存在微弱负相关。换句话说，短剧集的平均评分略高于长剧集。这个信号这两年越来越明显，短剧集（12-24集）的评分均值大约比长剧集（40集以上）高出 0.6 到 0.8 分。

不是说长剧集一定差，而是长剧集在创作上面临的内容稀释问题更严重，维持高水准的难度更大。这个发现没有让我太惊讶，但它能从数据角度验证“注水”现象确实在评分上付出了代价。

6.4 短评情绪分与评分的相关性验证

这部分是我后续加的，就是因为想回答“评分被刷了没有”这个问题。我把抓到的短评跑了一个简单的基于情感词典的情绪打分，用的是最朴素的正负面词匹配方法，没有上模型。每条短评给出一个 [-1, 1] 的极性得分，然后按剧集取平均。

拿这个“平均情绪分”去和短评样本里带星级的评分做相关性分析，我发现二者的相关系数大概在 0.82 左右，属于高度相关。这说明短评情绪和评分在方向上高度一致，样本偏差没有严重到影响结论。当然这个结果还比较粗，因为短评接口的样本偏向热门评论，不等于总体的无偏抽样。真要严谨地做情绪分析，应该采样更多短评，并且用分布偏移校正的方法加权，但作为偏好分析的补充，这个精度已经够了。

7. 落地过程中踩过的坑与规避方案

7.1 请求频率控制与反爬意识的平衡

这部分是我想强调的。做爬虫不是“技术够强就能为所欲为”，而是要尊重目标网站的服务能力。我在这个项目里坚持三条底线：第一，遵守目标的 robots.txt；第二，请求频率控制在每秒最多一次以内；第三，不做任何绕过登录或验证的操作。如果页面明确要求登录才能看，我就放弃这部分数据。

有一个反面教训可以分享：有一次我在测试短评接口时，为了快，把请求间隔调到了 0.2 秒，结果跑了不到十分钟 IP 就被临时限制了。这不是技术上绕过不了，而是我自己的节奏出了严重问题。后来我老老实实把间隔调回 2-3 秒，程序稳定跑了两天没出任何事。这个体验让我深刻明白：频率控制不仅是为了合规，也是保证任务能顺利跑完的前提。

我在写代码时用了一行非常简单的请求频率控制：

python复制last_request_time = 0
MIN_INTERVAL = 1.5  # 秒

def throttle():
    global last_request_time
    now = time.time()
    elapsed = now - last_request_time
    if elapsed < MIN_INTERVAL:
        time.sleep(MIN_INTERVAL - elapsed)
    last_request_time = time.time()

throttle() 放在每次请求之前调用，保证任何入口的请求都以至少 1.5 秒的间隔发出。相比手动写 sleep，这种方式不会因为重试逻辑而出现频率失控。

7.2 动态页面的几种识别与应对方式

如果你用一个 requests.get 拿到了 HTML，里面却找不到页面显示的数据，很可能就是遇到了动态渲染。最简单的识别方式是：打印 HTML 长度，再和浏览器里“查看源代码”的长度对比。如果明显少了一大截，基本可以确定是动态页面。

实际处理有几种路径，我的优先级是：

1. 在 Network 面板里找 XHR/JSON 接口，直接请求接口，这是效率最高、结构最干净的方案
2. 看页面 HTML 里的 window.__INITIAL_STATE__ 或 __NUXT__ 等全局变量，里面经常直接塞了一份完整数据
3. 用 Selenium 或 Playwright 模拟浏览器，但这是兜底方案，性能开销大而且很容易被识别

我在这个项目里只需要路径 1 就解决了。短评接口虽然看起来是动态的，但本质上是一个静态 JSON API，找到它就简单多了。

7.3 编码问题：你以为的字符串不是你以为的

网页编码是爬虫新手最容易忽略的坑。有的页面用 utf-8，有的用 gb2312，有的在 HTML 的 <meta charset> 里声明了但实际内容却是另一种编码。如果不用对编码，中文文本会变成一堆乱码。

解决办法是在 safe_get 函数里加一句：

python复制resp.encoding = resp.apparent_encoding

apparent_encoding 会基于内容自动猜测编码，比手动指定 utf-8 要更稳。当然它也有猜错的时候，所以更保险的做法是把 resp.content 传给 BeautifulSoup 时显式指定编码：

python复制soup = BeautifulSoup(resp.content, "lxml", from_encoding=resp.apparent_encoding)

针对 CSV 输出时的中文乱码，前面提到的 utf-8-sig 编码能解决 Excel 打开乱码的问题，但如果你用 pandas 读回数据，要记得 encoding="utf-8-sig" 也要对应上。

7.4 日志的重要性：爬虫必须看得见自己的状态

长时间运行的爬虫很容易变成“黑盒”，你不知道它当前在抓哪一页、失败了多少次、是不是已经卡住了。我的解决办法是给程序加日志，用 logging 而不是 print，因为 print 一旦把输出滚动出终端窗口，信息就没了。logging 可以写文件，可以在挂掉之后回溯问题。

python复制import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s | %(levelname)s | %(message)s",
    handlers=[
        logging.FileHandler("crawler.log", encoding="utf-8"),
        logging.StreamHandler()
    ]
)

这个日志配置既输出到文件又输出到终端，双保险。后期排查失败原因的时候，只需要去日志里搜索 ERROR 或者 HTTP 429 这样的关键词，而不用靠猜。

7.5 样本偏差与数据解读的诚实性

最后一点是对数据分析结果保持诚实的提醒。爬虫帮你拿到的数据只是平台公开内容的一个切片，不等于全量事实。比如短评接口按热度排序，热门短评会被高赞评论主导，情绪分布可能更极端；比如我只抓了评分人数超过 1000 的剧，这本身就过滤掉了一大批小众剧；又比如不同年份的剧集数量差异很大，2020 年以后的样本量明显多了，均值对比可能受样本结构影响。

在做观众偏好分析时，我一直提醒自己：数据能证伪一个假设，但不能百分百证明一个假设。比如我发现“集数和评分存在微弱负相关”，这可能是因为近两年的“精品短剧”趋势造成的，而非法则。分析报告里最好同时写清楚“我看到的现象”和“可能的解释”，不要把相关直接当成因果。

8. 后续还能怎么玩：从评分统计到内容推荐的进阶方向

这个项目做完之后，我并没有停在评分统计这一步。后续如果继续做，有几个方向我觉得很有意思：

一是做“评分预测”。把剧集的年份、集数、类型、主创阵容、演员历史作品评分等特征喂给一个简单的回归模型，预测这部剧上线后的评分区间。这个方向本质上是在做内容投资的辅助判断，虽然准确率不会特别高，但能对“高分剧长什么样”有一个定量认知。

二是做“观众偏好画像”。基于用户的短评文本做聚类分析，把观众分成几个偏好群体，比如“剧情党”“演员粉”“类型猎奇者”，再看不同群体的评分行为差异。这个需要更多用户维度的数据，但如果文本量足够大，聚类的结果会很有意思。

三是做“实时榜单监控”。把爬虫从一次性任务改成定时任务，每天抓一次评分变化，追踪剧集口碑的爬升与下降曲线。这个更像一个真实的监控系统，需要加上任务调度（APScheduler 或系统 crontab）、增量更新和趋势告警，复杂度再上一个台阶。

回头来看，这个项目的技术栈并不复杂，难点其实都在细节里：请求要稳，解析要准，清洗要细，分析要诚实。我的建议是，你拿到代码不要直接复制跑完就收工，而是把“爬下来的数据”当作一个待回答的生意问题，自己动手改字段、调参数、换一个你感兴趣的题材重新统计一遍。只有你真的被某个数据现象吸引了，想回头去解释它的时候，这个项目才算真正做进了脑子里。