Python爬虫实战：电商商品价格采集与数据分析全流程

1. 从需求到代码：这个价格分析爬虫到底在解决什么问题

先说个场景。我前阵子帮朋友做一份电商平台的类目价格报告，需求听起来特别简单：把某个类目下的商品价格全部拉下来，看看主流价位段集中在多少，低端、中端、高端分别有哪些品牌在卖。一开始我以为这活儿半小时就能搞定，结果手动打开网页一页一页翻，复制粘贴了不到五十条数据就崩溃了——商品数量过万，手动采集根本不现实。

这时候就需要一个能自动翻页、批量抓取、结构化存储的爬虫方案。本文要分享的正是这样一个实战项目：基于 Python 的电商类目商品价格分析爬虫，覆盖多页数据采集、价格区间统计分析，最终把数据导出为 CSV 文件，同时写入 SQLite 数据库做持久化。

注意：本文只讲公开商品信息（名称、价格、类目）的采集与统计分析，目标是个人学习与技术研究。分享的是通用技术思路，实际落地时请务必遵守目标网站的 robots 协议、相关法律法规，并控制请求频率，做个文明的爬虫开发者。

这个项目适合谁？刚学完 Python 基础语法、想拿真实项目练手的初学者，有一定爬虫经验但对数据存储和统计分析流程还不熟悉的中级开发者，以及需要快速做电商竞品价格调研的运营分析人员。无论你是哪个角色，看完这篇文章都能收获一套从采集到分析再到存储的完整闭环。

我会按真实的开发顺序来讲：先分析需求和技术选型，再手写单页采集代码，接着拆解多页翻页策略，然后做数据清洗和区间统计，最后分别实现 CSV 导出和 SQLite 持久化，并把整个过程中踩过的坑原原本本摆出来。

2. 开工前的技术选型与页面分析：为什么用 requests + BeautifulSoup 而不是 Selenium

2.1 请求库选型：requests 够用，就别上 Selenium

很多新手一上来就想用 Selenium 模拟浏览器，觉得"看起来更高级"。但我要泼一盆冷水：能不用浏览器渲染就用 requests。Selenium 需要额外安装浏览器驱动、占用大量内存、运行速度慢一个数量级，而且非常容易被反爬机制识别。对于静态渲染的商品列表页，requests 加合理的请求头就够了。

为什么选 requests？因为它极其轻量，只需要处理 HTTP 请求和响应，配合 BeautifulSoup 做 HTML 解析，整个链路清晰明了。我这次的目标页面是电商列表页，商品名称、价格、评论数等信息都直接渲染在 HTML 里，不需要执行 JavaScript 才能拿到数据，所以 requests 是最高效的选型。

python复制import requests
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",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8"
}

2.2 页面结构拆解：先看 HTML 再写代码，别闭眼硬写

写爬虫最忌讳的事情就是不看页面结构直接写选择器。我拿到目标页面后的第一步，是打开开发者工具（F12），逐个检查需要的字段落在哪个标签节点里。

以某电商平台的商品列表页为例，典型结构是这样的：每个商品卡在一个 <li class="gl-item"> 或 <div class="product-item"> 里，商品标题在 div.p-name a 的 title 属性或 em 标签里，价格在 div.p-price strong i 标签里，评论数在 div.p-commit strong a 标签里。用 BeautifulSoup 的 select_one 方法一个个抽取，比 find_all 再遍历更清晰。

python复制def parse_product(item):
    """从单个商品节点中提取信息"""
    title_tag = item.select_one("div.p-name a")
    title = title_tag.get("title", "").strip() if title_tag else ""
    
    price_tag = item.select_one("div.p-price strong i")
    price = price_tag.get_text(strip=True) if price_tag else "0"
    
    comment_tag = item.select_one("div.p-commit strong a")
    comments = comment_tag.get_text(strip=True) if comment_tag else "0"
    
    shop_tag = item.select_one("div.p-shop a")
    shop = shop_tag.get_text(strip=True) if shop_tag else "未知店铺"
    
    return {
        "title": title,
        "price": price,
        "comments": comments,
        "shop": shop
    }

这里有个很重要的经验：先跑通单条解析，再上全页循环。我一般会先取一个商品的 HTML 节点，写一个测试脚本跑一下，确认四个字段都能正确提取，再写批量解析。如果一上来就写完整流程，出了问题根本不知道是数据没抓到还是解析逻辑写错了。

2.3 数据模型设计：字段越简单越好，但关键字段不能漏

在设计数据存储结构之前，先想清楚要分析什么。标题里提到"价格分析"，那核心字段必须有商品名称、价格、评论数、店铺名。评论数可以用于加权分析——同样是 100 元的商品，一个卖了十万单，一个卖了十单，含金量完全不同。店铺名用于后续的品牌分布分析，属于可选项，但我建议加上，多个字段后期做分析时灵活很多。

原始的评论数字段里可能有"万"字后缀（比如"3.5万+"），价格字段里可能有"¥"符号或"起"字后缀。这些脏数据如果直接入库，后面的统计分析会非常痛苦。所以我在模型设计阶段就预留了一个清洗步骤，把数值型字段统一转为 float 或 int，把非数值内容过滤掉。这一步放在采集阶段做，比入库后再处理高效得多。

3. 多页数据采集的完整实现：从翻页逻辑到随机休眠

3.1 翻页参数解析：找到 URL 里的页码规律

多页采集的核心是找到翻页的 URL 规律。打开商品列表页后，手动点击第二页、第三页，观察地址栏 URL 的变化。比较常见的规律有两种：一种是路径参数式，比如 /list/xxx-0-0-0-0-0-0-0-0-0-0-0-0-0-1.html，最后一位数字代表页码；一种是查询参数式，比如 ?page=2&sort=default。

我这次遇到的正好是查询参数式，比较直观。用 page 参数控制页码，从第一页开始，每次循环加一。为了精确控制抓取范围，我封装了一个函数：传入类目 ID 和总页数，循环请求每一页，解析商品列表并累计到内存中的列表。

python复制def crawl_category(category_id, max_pages):
    """采集指定类目下前 max_pages 页的商品数据"""
    all_products = []
    base_url = f"https://example.com/list/{category_id}"
    
    for page in range(1, max_pages + 1):
        params = {
            "page": page,
            "sort": "default",
            "delivery": "1"
        }
        response = requests.get(base_url, headers=headers, params=params, timeout=10)
        status_code = response.status_code
        if status_code != 200:
            print(f"第{page}页请求失败，HTTP状态码：{status_code}")
            continue
        
        soup = BeautifulSoup(response.text, "html.parser")
        items = soup.select("li.gl-item")
        page_products = [parse_product(item) for item in items]
        all_products.extend(page_products)
        
        print(f"第{page}页采集完成，捕获商品{len(page_products)}条，累计{len(all_products)}条")
        
        # 反爬规避：随机休眠，避免请求频率过高
        time.sleep(random.uniform(1.5, 3.5))
    
    return all_products

3.2 判断翻页终点的几种方法：不要盲目跑满固定页数

很多教程会把"最多翻 50 页"写死，但这样做有隐患。如果类目总共只有 30 页数据，后面 20 页全是空的，白白浪费时间；如果数据超过 50 页，又会漏数据。我的做法是动态判断：每次拿到页面 HTML 后，检查是否存在商品节点；如果 items 为空列表，说明已经翻到最后一页，直接结束循环；如果存在分页组件，就从分页组件里解析总页数。

python复制def get_total_pages(soup):
    """从分页组件中解析总页数"""
    page_text = soup.select_one("div.page a.disabled")
    if page_text:
        # 文本通常类似 "共 100 页"
        match = re.search(r"共\s*(\d+)\s*页", page_text.get_text())
        if match:
            return int(match.group(1))
    # 兜底：没有分页信息时默认爬取固定页数
    return 50

动态判断还有一个好处：不同类目的商品数量差别很大，需求量大的类目有几百页，冷门类目可能就三五页。如果全部写死，要么抓不完整，要么做大量无用功。这个封装在前面的 crawl_category 函数里一改，整个采集过程就智能多了。

3.3 反爬应对：请求头、随机休眠、失败重试三板斧

电商平台的网站往往是反爬最严格的地方。我在实际采集过程中遇到的第一个问题就是请求头验证——不加 User-Agent 直接请求会被重定向到一个验证页面。所以请求头里必须带上完整的浏览器指纹，包括 User-Agent、Accept、Accept-Language 等字段。

第二个问题是请求频率。连续快速请求会被判定为机器行为，返回 503 或滑块验证。我的做法是在每页请求之间使用 time.sleep(random.uniform(1.5, 3.5))，让请求间隔呈现自然波动，而不是固定等待。这个随机区间不需要太长，1.5 到 3.5 秒足够模拟真实用户的翻页节奏，整体采集几千条数据大约需要十几分钟，完全在可接受范围内。

第三个问题是请求失败。网络不稳或页面结构临时调整都可能导致请求失败，所以我加了重试机制：使用 requests.Session 复用连接，配合循环重试三次，每次重试前等待 3 秒。下面的代码展示了带重试机制的请求封装：

python复制def fetch_page(session, url, params, max_retries=3):
    """带重试机制的页面请求"""
    for attempt in range(1, max_retries + 1):
        try:
            response = session.get(url, headers=headers, params=params, timeout=10)
            if response.status_code == 200:
                return response
            else:
                print(f"请求返回状态码 {response.status_code}，第{attempt}次重试")
        except requests.RequestException as e:
            print(f"请求异常：{e}，第{attempt}次重试")
        
        if attempt < max_retries:
            time.sleep(3)  # 重试前等待
    
    return None

这里要特别强调：反爬规避的根本原则是"别给对方服务器添麻烦"。延迟调大一些、频率调低一些，不仅安全，采集到的数据的完整率也更高。我试过把延迟调到 0.5 秒，结果爬到第 15 页就被封了 IP，得不偿失。

4. 价格数据的清洗与区间统计：把脏数据变成可分析的结构化数据

4.1 数据清洗：正则表达式统一处理价格和评论数字段

采集完成后，数据是原始的字符串状态，比如价格字段可能是 "¥129.00" 或 "1099.00起"，评论数字段可能是 "3.5万+" 或 "2000+"。这些字符串不能直接参与统计运算，必须先清洗成 float 或 int。

价格清洗的逻辑是：用正则表达式提取第一个合法的数字，然后转成 float。如果出现 "xx起" 这种标记，直接忽略起字，只取价格本体。评论数的清洗稍复杂，因为有万、亿这种数量级单位，需要单独处理"万"后缀并乘以 10000。

python复制import re

def clean_price(price_str):
    """清洗价格字符串，返回 float 类型"""
    if not price_str:
        return 0.0
    # 提取类似 129.00、1099 的数字部分
    match = re.search(r"\d+(\.\d+)?", price_str)
    return float(match.group()) if match else 0.0

def clean_comments(comment_str):
    """清洗评数字符串，返回 int 类型"""
    if not comment_str:
        return 0
    # 处理 "3.5万+" 格式
    match = re.search(r"([\d.]+)(万)?", comment_str)
    if not match:
        return 0
    value = float(match.group(1))
    if match.group(2) == "万":
        value *= 10000
    return int(value)

清洗这一步是整个项目中性价比最高的工作。数据入库后再发现问题，改起来费时费力，而采集阶段顺手清洗，后面分析和导出的每一步都顺畅。

4.2 区间统计的设计思路：分桶统计比平均数更有洞察力

拿到清洗后的价格列表，第一反应可能是算平均价和最高最低价。但平均数很容易被极端值带偏——一个商品卖 99999 元，五个商品卖 100 元，平均价一下子就变成了悬殊的数字。做价格分析时，更有价值的是价格区间分布：30 元以下有多少款，30-50 元有多少款，50-100 元有多少款，以此类推。这种分桶统计才能看出市场的真实结构。

分桶的边界可以根据类目特点自定义。我这次做的类目主流价格带在 20-200 元，所以分桶设计为：0-30、30-50、50-100、100-200、200-500、500+ 六个区间。用 Python 实现分桶统计非常简单：

python复制def analyze_price_distribution(prices, buckets):
    """
    按区间统计价格分布
    buckets: [(0, 30), (30, 50), (50, 100), (100, 200), (200, 500), (500, float('inf'))]
    """
    distribution = {}
    for low, high in buckets:
        if high == float("inf"):
            label = f"{low}+"
        else:
            label = f"{low}-{high}"
        distribution[label] = 0
    
    for price in prices:
        for low, high in buckets:
            if low <= price < high:
                if high == float("inf"):
                    distribution[f"{low}+"] += 1
                else:
                    distribution[f"{low}-{high}"] += 1
                break
            elif price >= 500 and high == float("inf"):
                distribution["500+"] += 1
                break
    
    return distribution

这段代码的输出是一个字典，key 是区间名称，value 是落入该区间的商品数量。有了这个分布，你可以直接看出这个类目的市场定位：如果 0-30 元的商品占了大头，这就是一个低客单价走量的类目；如果 200-500 元区间商品最多，说明市场偏中高端，定价时要参考这个区间。

4.3 手动构造一个简单的统计汇总结构

光有区间分布还不够，我还习惯生成一个汇总信息，包括商品总数、平均价格、价格中位数、最高价、最低价、评论总数。这里用一个数据类来承载统计结果：

python复制from dataclasses import dataclass

@dataclass
class Statistics:
    total_count: int
    avg_price: float
    median_price: float
    max_price: float
    min_price: float
    price_std: float
    total_comments: int

平均价格直接 sum(prices) / len(prices)，中位数需要先排序再取中间值。这些统计量配合区间分布，足够写出一份有说服力的价格分析报告了。

python复制def compute_statistics(prices, comments):
    """计算价格汇总统计量"""
    total = len(prices)
    avg = sum(prices) / total if total else 0
    sorted_prices = sorted(prices)
    median = sorted_prices[total // 2] if total else 0
    if total % 2 == 0 and total > 1:
        median = (sorted_prices[total // 2 - 1] + sorted_prices[total // 2]) / 2
    variance = sum((p - avg) ** 2 for p in prices) / total if total else 0
    std = variance ** 0.5
    
    return Statistics(
        total_count=total,
        avg_price=avg,
        median_price=median,
        max_price=sorted_prices[-1] if total else 0,
        min_price=sorted_prices[0] if total else 0,
        price_std=std,
        total_comments=sum(comments)
    )

标准差（price_std）这里特别值得关注。它反映的是价格的离散程度。标准差大，说明这个类目的商品价格跨度很大，高中低档混卖；标准差小，说明价格高度集中，市场竞争大概率非常激烈。

5. CSV 导出与 SQLite 持久化：一份数据用两种方式保存，各取所长

5.1 CSV 导出的正确姿势：utf-8-sig 编码避免 Excel 乱码

CSV 导出是分析结果的直接交付物，也是最容易踩坑的地方。最常见的坑是：用默认的 UTF-8 编码写的 CSV，用 Excel 打开时中文全部乱码。原因是 Excel 默认用 GBK 编码解析 CSV 文件，而 Python 的 csv 模块默认写的不是 GBK。

解决方案有两种：一是写文件时指定 encoding="utf-8-sig"，这种编码会在文件头部加上 BOM 标识，Excel 能自动识别；二是直接指定 encoding="gbk"。我推荐第一种，因为 utf-8-sig 的兼容性更好，其他数据分析工具（比如 pandas、Tableau）读起来也没有问题。

python复制import csv

def export_to_csv(products, filepath):
    """将商品数据导出为 CSV 文件"""
    fieldnames = ["title", "price", "comments", "shop"]
    with open(filepath, "w", newline="", encoding="utf-8-sig") as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)
        writer.writeheader()
        writer.writerows(products)
    print(f"CSV 文件已导出到：{filepath}，共 {len(products)} 条数据")

这里有个细节：打开文件时一定要加 newline="" 参数，否则在 Windows 系统上每两行之间会多一个空行，这是 csv 模块的经典坑之一，很多人第一次写都会遇到。

导出的 CSV 结构包含三列：排行、商品标题、价格、评论数、店铺名。用 Excel 打开后，可以直接对价格列做排序、筛选、制作透视表。CSV 的价值在于通用性，任何工具都能打开，适合做报表分享和人工二次分析。

5.2 SQLite 建表与数据入库：SQL 参数化插入防止注入

SQLite 的选择很合理。它是一个零配置的嵌入式数据库，不需要单独安装数据库服务器，就是一个 .db 文件，写完代码直接运行就能建库建表。对单机爬虫项目来说，SQLite 的性能完全够用——几万条数据的插入和查询都是毫秒级别的。

建表语句考虑设计一个商品表，包含 id 自增主键、商品标题、价格（REAL 类型存储浮点数）、评论数（INTEGER）、店铺名、采集时间戳。采集时间字段很关键，方便后期做历史数据对比——同一类目下周再跑一次，就能看出价格波动。

python复制import sqlite3

def init_database(db_path):
    """初始化 SQLite 数据库和商品表"""
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS products (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            title TEXT NOT NULL,
            price REAL NOT NULL,
            comments INTEGER DEFAULT 0,
            shop TEXT,
            collected_at TEXT DEFAULT CURRENT_TIMESTAMP
        )
    """)
    conn.commit()
    conn.close()

插入数据时，牢记一条铁律：永远使用参数化查询，不要用字符串拼接 SQL。字符串拼接不仅存在 SQL 注入风险，更重要的是遇到引号、特殊字符时会导致插入失败——商品标题里经常出现单引号、双引号、百分号，直接拼接十有八九会报错。

python复制def insert_products(products, db_path):
    """将商品数据批量插入 SQLite 数据库"""
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    insert_sql = """
        INSERT INTO products (title, price, comments, shop)
        VALUES (?, ?, ?, ?)
    """
    # 先清洗再入库
    cleaned_data = [
        (p["title"], clean_price(p["price"]), clean_comments(p["comments"]), p["shop"])
        for p in products
    ]
    cursor.executemany(insert_sql, cleaned_data)
    conn.commit()
    conn.close()
    print(f"已插入 {len(products)} 条数据到 SQLite 数据库")

executemany 是批量插入的高效写法，一次性传入一个列表，比逐条循环插入快很多。两万条数据，逐条插入大概要 2-3 秒，executemany 几十毫秒就能完成。

5.3 两种存储方案怎么选：数据分析用 CSV，增量管理用 SQLite

经常有人问：既然都存到 SQLite 了，为什么还要导出一份 CSV？这不是冗余操作吗？我的答案是：两者解决的问题不同。

CSV 是给人和通用工具用的。发给同事做市场调研，对方用 Excel 打开就能筛选、排序，不需要安装任何数据库软件。CSV 是一份快照，记录的是本次采集的完整数据。

SQLite 是给程序用的。我的 SQLite 数据库像是一个持续累积的仓库，每次跑完爬虫，新数据追加到表里，历史数据不丢。后续做价格趋势分析时，直接写 SQL 查询某时间段内的数据，比解析 CSV 方便得多。

打个比方：CSV 就像你手机上拍的照片，拍完就能直接分享；SQLite 就像一个云相册，自动把所有照片归档存储，方便日后检索。两者并不冲突，而是各司其职。这个双写方案在项目里只需要多花十几行代码，收益却非常明显。

6. 全流程串联与运行结果验证：主函数怎么组织、数据怎么检验

6.1 主流程编排：初始化、采集、清洗、统计、导出、入库一个不漏

把前面的模块组合起来，主函数的结构非常清晰。整个流程分成六步：第一步初始化数据库连接，创建一个会话对象；第二步采集数据，指定类目 ID 和最大页码；第三步清洗数据；第四步计算统计信息；第五步导出 CSV；第六步写入 SQLite。

python复制def main():
    # 配置参数
    CATEGORY_ID = "12345"          # 替换为实际的类目 ID
    MAX_PAGES = 50                 # 最大采集页数
    CSV_PATH = "products.csv"
    DB_PATH = "products.db"
    
    # 初始化步骤
    init_database(DB_PATH)
    session = requests.Session()
    session.headers.update(headers)
    
    # 采集步骤
    print("开始采集数据...")
    products = crawl_category(session, CATEGORY_ID, MAX_PAGES)
    if not products:
        print("未采集到数据，程序退出")
        return
    
    # 统计步骤
    prices = [clean_price(p["price"]) for p in products]
    comments = [clean_comments(p["comments"]) for p in products]
    stats = compute_statistics(prices, comments)
    
    print(f"商品总数：{stats.total_count}")
    print(f"平均价格：{stats.avg_price:.2f}")
    print(f"价格中位数：{stats.median_price:.2f}")
    print(f"最高价：{stats.max_price:.2f}")
    print(f"最低价：{stats.min_price:.2f}")
    print(f"价格标准差：{stats.price_std:.2f}")
    print(f"评论总数：{stats.total_comments}")
    
    # 区间分布
    buckets = [(0, 30), (30, 50), (50, 100), (100, 200), (200, 500), (500, float("inf"))]
    distribution = analyze_price_distribution(prices, buckets)
    for label, count in distribution.items():
        print(f"价格区间 {label} 元：{count} 款")
    
    # 导出步骤
    export_to_csv(products, CSV_PATH)
    insert_products(products, DB_PATH)
    
    print("全流程执行完毕")

if __name__ == "__main__":
    main()

这种模块化组织的思路，让每个环节都能独立测试和调整。比如我只想重新跑统计、不想重新采集，就可以把采集结果保存一份，跳过前面的步骤直接复用。

6.2 用图表辅助验证：画一个价格分布柱状图

没有图表的统计数据总觉得缺点肉。我习惯用 Python 自带的 matplotlib 画一个简单的柱状图，直观展示价格区间分布。虽然这不是必须步骤，但对快速理解数据非常有帮助。

python复制import matplotlib.pyplot as plt

def plot_distribution(distribution, category_name):
    labels = list(distribution.keys())
    values = list(distribution.values())
    
    plt.figure(figsize=(10, 6))
    plt.bar(labels, values, color="skyblue")
    plt.title(f"{category_name} 价格区间分布")
    plt.xlabel("价格区间（元）")
    plt.ylabel("商品数量")
    plt.tick_params(axis="x", rotation=45)
    plt.tight_layout()
    plt.savefig("price_distribution.png", dpi=150)
    plt.show()

跑了这个图之后，数据会说话。比如你可能发现 30-50 元这个区间占了接近一半，那么对这个类目的结论就很清晰：这是一个低价走量的市场，中高端产品生存空间有限，进入这类市场前要想清楚差异化策略。

6.3 验证数据质量的几个自检点：采集完别急着交付

数据采集完，别急着把 CSV 发给别人。我会做几个快速自检，确保数据质量没问题。

第一是数量检查。如果设置采集 50 页、每页 30 条商品，理论上应该有 1500 条数据。实际采集可能因为个别页面请求失败而略有误差，但如果差了太多，说明翻页逻辑或请求策略有问题。第二是价格合理性检查。筛选一下价格字段里有没有奇葩值，比如 0.01 元的商品、价格超过十万的商品，这些可能是促销占位数据或者异常值，需要确认是否保留。第三是重复检查。电商列表页偶尔会出现商品重复的情况，我一般用 title + price 作为去重键，把重复项过滤掉。

python复制def deduplicate(products):
    """简单去重：基于标题和价格的组合"""
    seen = set()
    unique_products = []
    for p in products:
        key = (p["title"], p["price"])
        if key not in seen:
            seen.add(key)
            unique_products.append(p)
    return unique_products

这几步自检虽然不复杂，但能避免很多返工。我见过不少人拿着原始未清洗的数据去做分析，结论完全被脏数据带偏，最后不得不重新跑一遍流程，浪费时间不说，还容易给人留下不专业的印象。

7. 真实踩坑记录：翻页漏数据、Excel 乱码、SQLite 锁冲突

7.1 翻页参数漏传导致重复采集同一页数据

这是我第一次跑完整流程时遇到的最隐蔽的坑。我原以为控制 page 参数就能正常翻页，跑了几分钟后发现去重检查时大量重复数据——仔细排查后发现，有些列表页的 URL 除了 page 参数之外，还有 delivery 和 sort 参数。如果只传 page 参数不传其他参数，服务器会忽略 page 变化，始终返回第一页的数据。

教训是：写翻页逻辑之前，一定用浏览器手动点一到第五页，仔细观察 URL 的完整变化规律，把所有变化的参数都纳入请求。有些页面还会把 sort 参数隐藏在 Form Data 里，这种就用 POST 请求。这次我遇到的还好是 GET 请求，只是参数不全，改正后翻页就正常了。

7.2 使用 utf-8-sig 之前：CSV 中文乱码痛不欲生

关于 CSV 乱码，虽然前面已经说了解决方案，但我还是想重点强调这个坑出现的频率。我第一次导出 CSV 时用的是最普通的 with open(filepath, "w", newline="", encoding="utf-8")，结果用 Excel 打开全是乱码，当时第一反应是数据采集出问题了，查了半天才发现是编码格式的问题。

提示：如果你用 pandas 读取 CSV，utf-8-sig 也完全兼容，不会影响后续程序处理。所以不需要纠结，"写入 CSV 时统一用 utf-8-sig"就是最佳实践。

7.3 SQLite 锁冲突：读写并发时的"database is locked"

SQLite 的锁机制和 MySQL、PostgreSQL 这些数据库不同。SQLite 对并发写入的支持很弱，同一时刻只允许一个写操作。如果爬虫多进程并发写入同一个数据库文件，大概率会遇到 sqlite3.OperationalError: database is locked 错误。

解决这个问题有三条路。第一条最简单：目进程去掉，单线程写库，这是爬虫脚本最常见的方式。第二条是给连接设置超时和 busy_timeout 参数，让等待中的事务稍等片刻：

python复制conn = sqlite3.connect(db_path, timeout=10)
conn.execute("PRAGMA busy_timeout = 10000")

第三条是对数据量大的场景，把数据先攒到内存列表里，最后用一次 executemany 批量插入，尽量减少锁的持有时间。三条路可以组合使用，按我的经验，爬虫项目单线程写库基本不会遇到性能瓶颈。

7.4 请求频率过高被临时限制：怎么判断是被封了还是正常反爬

爬得正上头，突然所有请求都返回 503，这是所有爬虫开发者都经历过的崩溃时刻。我的经验是：先看响应内容里是否有验证码关键词或跳转链接，再看 HTTP 状态码。如果响应状态码是 403 或 503，且响应内容里有"验证码""异常流量"之类的关键词，基本可以确定被临时限制了。

处理方式不是硬刚，而是停下来降低频率。我一般会暂停 5-10 分钟，把休眠时间从 1.5-3.5 秒提升到 3-5 秒，如果还是不行就换一个代理 IP。高频率不对，低频率最实际。一次采集几千条数据，用低速稳定的策略跑完，虽然多花几分钟，但至少不会中断重来。

8. 扩展到其他采集场景：这套代码怎么改造成通用爬虫框架

8.1 把选择器变成配置：一套代码兼容多个站点

项目跑通之后，我不满足于只爬这一个类目，还想分析其他电商平台的同类数据。面对不同站点的不同 HTML 结构，最有效的做法是把选择器抽取成配置字典，而不是为每个站点重新写一套解析逻辑。

配置化的设计思想很简单，就是在代码里维护一个字典，记录每个站点的商品容器选择器和各字段选择器：

python复制SITE_CONFIGS = {
    "example_a": {
        "item_selector": "li.gl-item",
        "title_selector": "div.p-name a",
        "price_selector": "div.p-price strong i",
        "comments_selector": "div.p-commit strong a",
        "shop_selector": "div.p-shop a",
    },
    "example_b": {
        "item_selector": "div.item",
        "title_selector": "div.title",
        "price_selector": "span.price",
        "comments_selector": "span.review",
        "shop_selector": "div.seller",
    }
}

采集时只需要把配置传给解析函数，解析函数根据配置动态获取字段值。这样做的收益是巨大的：以后新增一个站点，只需要研究页面结构、写一组选择器配置，核心采集逻辑完全不用动。

8.2 定期任务化：定时运行爬虫做价格趋势监控

单次采集只能获得静态画像，如果想长期监控价格走势，可以把爬虫脚本挂到定时任务上。在 Linux 系统用 cron，在 Windows 系统用任务计划程序，设置每天凌晨两点运行一次。

价格趋势监控的价值在于，你很快就能发现数据变化。比如某款商品平时稳定在 100 元左右，大促前夜突然涨到 150 元，这是典型的"先涨价后降价"套路。如果你只有单次快照数据，这种动态变化很难被察觉。有了 SQLite 的历史累积，查一下商品的访问时间序列，趋势一目了然。

python复制# SQL 查询某商品的历史价格变化（示例语句）
SELECT price, collected_at FROM products
WHERE title LIKE ?
ORDER BY collected_at DESC

8.3 合规意识：爬虫不是"想爬就爬"

最后分享一点经验，也是最重要的。写爬虫的技术难度其实不高，真正的门槛在合规意识。每个网站都有自己的 robots 协议和数据使用条款，做任何爬虫项目之前，先确认目标网站允许不允许爬取，以及采集到的数据能怎么用。

如果要做商业分析，建议优先考虑使用平台开放的官方 API。API 稳定、合规、数据质量高，虽然有时候有限流，但对绝大多数分析需求来说完全够用。本文的爬虫方案更适合用于学习研究、原型验证、以及平台方明确允许爬取的公开数据场景。守住合规底线，技术才能真正为业务创造价值，这一点希望每个读者都记住。