做电商爬虫这行时间久了你会发现真正决定一个采集项目能不能稳定跑下去的往往不是解析规则写得有多巧妙而是最底层的请求环节靠不靠谱。我自己用 xxxwww 这个轻量请求模块搭过好几套电商采集链路从商品列表到详情页再到价格库存监控说实话踩过的坑比写过的规则还多。这篇文章就把 xxxwww 在电商爬虫里的实际应用拆开讲清楚包括它到底承担什么角色、怎么配置连接与会话、如何配合解析和数据落地以及那些常规文档里根本不会写的高频问题。内容比较偏实战适合已经写过一点爬虫、但想把自己采集脚本做得更稳的读者。如果你只是刚接触爬虫也能跟着步骤跑通一套完整的采集管道后面再慢慢理解每个参数背后的原理。1. 先搞清楚 xxxwww 在电商爬虫里承担什么角色1.1 一条完整电商采集链路请求层为什么最关键大多数人聊爬虫注意力都在解析和反爬容易忽略一件事电商页面结构再复杂、验证逻辑再多最终都要落到“能不能稳定拿到 HTML 或 JSON”这个前提上。抓不到数据后面所有解析都是空中楼阁。一条典型的电商采集链路大概是这样的任务调度器把待采集的 URL 交给请求模块请求模块负责发起网络请求、处理 Cookie、跟随重定向、应对超时和临时封禁拿回响应之后再由解析模块抽取字段最后清洗落库。这里面的请求模块就是 xxxwww 的核心位置。之所以说它最关键是因为电商站点的请求特征很特殊。商品列表页和详情页动辄几百上千个字段一个页面里有大量图片和异步接口请求频率一高服务器的连接池、DNS 解析、TLS 握手这些环节都会成为瓶颈。xxxwww 在真实项目里帮我解决的就是把这些底层细节收敛成一个稳定可控的请求入口让上层业务只关心“给我这个 URL我拿到内容”。1.2 xxxwww 的定位把“拿到网页”这件事做扎实很多新手喜欢一上来就上 Scrapy 或者 Playwright其实早期阶段没必要。Scrapy 的学习成本和框架约束都不低Playwright 要起浏览器内存开销也大。电商采集的很多场景尤其是价格监控、库存变化、榜单更新本质上都是高频小请求一个轻量级的请求模块反而更合适。xxxwww 在我看来就是干这个的。它不替你解析页面也不替你管理任务队列而是把 HTTP 请求层做厚连接池复用、会话保持、超时控制、重试策略、请求头管理这些事它都给你留好了口子。你只需要告诉它“我要访问哪个地址、带什么参数、多久算超时”剩下的网络细节它来处理。我在项目里的习惯是把 xxxwww 再包一层做成项目自己的 fetch 函数。这样所有请求都走同一个入口统一打日志、统一加公共请求头、统一处理异常后面排查问题的时候特别方便。这个习惯让我少加了不少班。1.3 选型对比为什么不用重量级框架直接上这里不是否定重量级框架而是说场景要匹配。电商采集链路里如果任务量是每天几千个商品用 xxxwww 这种轻量模块就够了如果每天几百万级 URL那确实需要 Scrapy 的调度和去重能力。但大部分中小团队和个人项目远没到那个量级用轻量模块反而更灵活。我拿三个方案做对比大家感受一下方案上手成本资源占用灵活度适合场景xxxwww 自建管道低低高中小规模采集、监控类脚本Scrapy中高中中大规模分布式采集Playwright/Selenium低API友好很高中强交互页面、JS 渲染严重的站点选择 xxxwww 还有一个实际考虑它对环境要求低部署到一台小服务器上就能跑不像浏览器自动化那样动辄要 1G 以上内存。实测下来单机跑十几个采集任务CPU 和内存占用都很稳。这也意味着你可以把更多资源留给数据处理和存储环节。2. 动手前先想清楚这些事目标规则与会话模型2.1 先去看目标站点的爬虫协议别上来就怼这步看起来不起眼但其实非常重要。电商站点一般都会提供 robots.txt里面会明确哪些路径允许抓取、哪些不允许还经常有 Crawl-delay 字段告诉你请求间隔的建议值。合规采集的第一步就是尊重这些规则。我拿到一个电商目标之后会先手动访问一下站点把商品类目、列表页、详情页的 URL 规律摸清楚。同时确认数据是服务端渲染还是前端异步加载。如果页面内容要靠接口返回那 xxxwww 的主要请求对象就是那些 JSON 接口而不是 HTML 页面。这样定位清楚之后后面写规则才有方向。这里尤其要注意很多电商站点的分类筛选是带参数的 URL比如?page2sortprice。这种参数规律最好在浏览器里先点一遍把 URL 变化记录下来再在代码里动态拼参数。我写采集逻辑时很少硬编码 URL基本都是参数化拼接这样后续加类目、改排序只要改配置。2.2 连接池与会话保持的正确打开方式电商页面里有很多静态资源是同一个域名下的如果每次请求都重新建立 TCP 连接和 TLS 握手效率会低得离谱。xxxwww 在连接管理上做了连接池复用同一个 host 的连接可以重复使用大幅减少握手开销。我实际使用时的配置思路是创建一个全局的会话对象所有请求都通过这个会话发出。会话对象会帮我们自动管理 Cookie同时也复用底层连接。如果你每个请求都新建一个会话不仅 Cookie 断掉连接也没法复用性能差距非常明显。我试过用同一个会话连续抓取同一站点上百个商品页响应时间往往能稳定在 300ms 到 800ms 之间。如果每次请求都重新建连延迟直接翻倍。所以“一个会话走天下”是电商采集里特别值得养成的习惯。2.3 Header 与 Cookie 的细节像真实访客一样访问很多反爬策略的第一道关卡就是请求头检查。电商站点通常会校验 User-Agent、Referer、Accept-Language 这些字段。用 xxxwww 请求时建议把浏览器里常见的请求头完整带上。这里有个小细节Referer 字段特别容易被忽略但很多电商站点的图片和接口都会校验它。我通常会在请求模块里维护一份默认请求头不同场景再去覆盖。比如访问列表页时 Referer 设置为首页访问详情页时 Referer 设置为对应的列表页 URL。这样整个访问轨迹看起来更像真人操作。Cookie 这块就更重要了。首次访问电商站点服务器通常会下发一些标识用的 Cookie后续请求都要携带。用 xxxwww 的会话对象可以直接免去手动维护 Cookie 的麻烦但如果你的采集任务需要模拟登录那就得手动管理登录态和 Cookie 的更新时机。常见做法是把登录后的 Cookie 序列化保存到本地过期后再重新登录。3. 实操用 xxxwww 搭一套商品信息采集管道3.1 先把采集目标和字段模型定下来前面铺垫了那么多终于到动手环节。我习惯先定义清楚要什么字段再写请求代码这样可以避免后面反复改解析逻辑。比如我们要采集某个电商类目下的商品信息核心字段一般是商品 ID、标题、价格、月销量、库存状态、店铺名称、详情页 URL。这些字段定义好之后再确定数据结构。日常开发里我直接用字典列表跑通后再根据数据量决定写 CSV 还是入库。下面是一个最小可用的字段模型fields { product_id: , title: , price: 0.0, month_sales: 0, stock_status: , shop_name: , detail_url: , }这一步看着简单但对整个采集管道的稳定性影响很大。字段模型清晰了后面的解析、清洗、去重才能有条不紊。不要嫌这一步麻烦后期改字段可比前期定义字段痛苦多了。3.2 名单页请求与翻页先写一个能跑的循环接着进入核心请求环节。我们先用 xxxwww 请求榜单页拿到商品列表数据。为了方便理解我这里假设榜单页返回的是 JSON 数据这也是目前很多电商接口的常见形式。import xxxwww session xxxwww.Session() DEFAULT_HEADERS { User-Agent: Mozilla/5.0 ..., Accept: application/json, text/plain, */*, Referer: https://example.com/, } def fetch_list(page): url https://example.com/api/rank params { page: page, page_size: 50, sort: default, } resp session.get(url, headersDEFAULT_HEADERS, paramsparams, timeout(5, 15)) resp.raise_for_status() return resp.json()代码里我设置了 timeout而且是(5, 15)这种元组形式分别代表连接超时和读取超时。这是电商采集里很实用的配置方式连接超时短一点5 秒连不上就放弃读取超时长一点给服务器处理请求留足时间。跑通单页之后翻页逻辑就顺理成章了。要特别注意循环里的异常处理别让一个页面超时导致整个任务中断。我一般会给单页请求包一层异常捕获失败则记录日志后跳过同时统计失败次数连续失败超过阈值就主动终止任务。3.3 详情页请求批量取数据时要有点耐心列表页拿到的是商品 ID 和摘要信息详情页才是完整数据的来源。批量采集详情页时最忌讳的就是无脑 for 循环一口气请求完所有 URL。服务器不是傻子一秒几十个请求的节奏很容易触发风控。我用 xxxwww 跑详情页时会设置一个请求间隔通常在 0.5 到 2 秒之间随机波动。随机不是为了做坏事而是让请求节奏更接近真人操作降低对目标服务器的压力。这种对双方都友好的采集节奏才是长期能跑下去的关键。另外详情页返回的数据格式往往更复杂可能是嵌套的 JSON也可能是 HTML 里嵌着 JSON 数据。遇到后者我的做法是先用正则或者字符串查找把 JSON 块切出来再用解析库转成字典而不是对着 HTML 硬写选择器。这样代码更稳定因为页面结构可能变但内嵌的数据格式一般变化较小。import re import json from parsel import Selector def fetch_detail(product_id): url fhttps://example.com/product/{product_id} resp session.get(url, headersDEFAULT_HEADERS, timeout(5, 15)) html resp.text # 从页面里提取内嵌 JSON 数据块 match re.search(rwindow.__INITIAL_STATE__ ({.*?});, html) if match: return json.loads(match.group(1)) # 如果没找到 JSON 块退回 HTML 解析 selector Selector(texthtml) return { title: selector.css(h1.product-title::text).get(), price: selector.css(span.product-price::text).get(), }这段代码展示了两种解析策略的切换。实际项目里我经常是先试着取 JSON 块取不到再用 HTML 选择器兜底。多一层兜底代码就多一分健壮性。3.4 频率控制、重试与失败恢复让脚本能挂机跑一夜写采集脚本最怕什么最怕半夜脚本挂掉第二天起来一看跑了三小时全白跑。所以频率控制和失败恢复能力是衡量一个采集脚本是否合格的重要标准。频率控制方面除了前面说的随机间隔还可以加一个简单的分钟级限速。比如每分钟最多请求 30 次超过就休眠。这种限速逻辑用 xxxwww 也容易实现包一层计数判断就行。重试机制同样重要。网络抖动、服务器 5xx 错误这些都是不可避免的。我一般在请求函数里加一个重试装饰器对连接超时、读取超时和 5xx 状态码做最多 3 次重试。重试间隔采用递增策略比如第 1 次等 1 秒、第 2 次等 3 秒、第 3 次等 5 秒避免在服务器还没恢复时反复冲击。失败恢复方面我会把每批任务的进度实时写入一个任务表记录哪些商品 ID 已成功、哪些失败。重新跑的时候只补采失败的那部分就行。这个机制救过我很多次尤其当采集任务跑到一半被中断时不需要从头再来。3.5 数据清洗与落库采集的最后一步不是请求数据拿到手之后还有一道清洗的工序。电商数据里最常见的脏数据包括价格字段带货币符号、销量字段是“1万”这种中文格式、库存状态是空字符串。这些都需要在落库前统一处理。我的清洗逻辑一般分三步第一步类型转换把价格、销量转成数值类型第二步格式统一比如把“1万”转成 10000第三步去重同一个商品 ID 只保留最新记录。三步做完之后再决定存到 CSV 还是数据库。如果是个人小项目存 CSV 就够用简单直接。但如果要做长期监控和趋势分析建议落到 SQLite 或者 MySQL。我自己做过一套价格监控就是把每日价格写入 SQLite然后用一个简单查询看价格波动。数据量不大但胜在稳定跑几个月都没出过问题。4. 高频问题排查实录这些坑我替你先踩了4.1 请求被断开Connection Reset 怎么定位这是电商爬虫最经典的问题之一通常不是单一原因而是多个因素叠加。我遇到这种情况第一反应不是加代理而是先检查自己的请求频率。很多时候就是同一个 IP 请求太密集触发了服务端的连接保护。先把请求间隔拉长观察几分钟如果问题消失那就是频率问题。还有一种可能是 HTTP 版本问题。有些服务端对 HTTP/1.1 的 keep-alive 连接处理比较激进长连接空闲太久会被重置。解决方法是请求前设置 Connection 头部或者定期重建会话对象避免连接长时间空闲。我的排查顺序是请求频率 → 会话状态 → 请求头完整性 → 本地网络出口。按照这个顺序排查大部分 Connection Reset 都能找到原因。4.2 返回内容出现乱码或者大量空数据乱码问题大多是编码判断出错。很多站点在响应头里没有明确声明 charset或者在 HTML 的 meta 标签里才写明编码。xxxwww 拿到的响应内容需要先判断编码再解码不能直接按默认编码处理。我的办法是优先看响应头里的Content-Type如果没有 charset就解析 HTML 里的 meta 标签再用检测库识别编码。这套流程写成一个小函数基本上能覆盖绝大多数中文站点的编码问题。空数据的问题则复杂一些。接口返回 200 但 body 是空或者 JSON 解析出来是空列表一般是因为参数缺失、地区限制或者请求头里缺少某个认证信息。这时候别急着改代码先用浏览器手动请求同一个接口用开发者工具对比请求头差异通常很快能找到原因。4.3 采集到一半突然开始返回验证码页面这种情况说明你的请求节奏已经被目标站点标记了。最直接的处理是立刻降低频率让脚本暂停一段时间同时检查请求头、Cookie 是否有缺失。如果你已经大量请求了几千个页面建议换个出口 IP 再继续。但有几个合规提醒想多说一句不要尝试破解验证码不要去研究绕过风控的灰色技巧。电商爬虫的正道是控制合理频率、遵守站点规则、优先采集公开数据。作为采集技术的使用者我们对目标服务器的资源负载负有责任。保持克制反而能跑得更久。4.4 高频问题速查表现象可能原因处理建议Connection Reset请求频率过高或连接空闲超时降低频率、定期重建会话返回乱码编码识别错误自行检测并指定正确编码空数据/空列表参数缺失或地区限制对照浏览器请求排查参数突然出现验证码触发风控策略暂停采集、降低速度、检查请求头响应超时目标接口响应慢调大读取超时开启重试被限制访问IP 被短期限制暂停一段时间避免继续请求这张表我贴在自己的项目文档里每次脚本出问题就先查一遍能省下大量排查时间。5. 一点经验体会做了这么久的电商采集我越来越觉得稳定压倒一切。一个能稳定跑数据的轻量脚本比一个功能花哨但三天两头挂掉的框架实用得多。xxxwww 在我的项目里一直扮演着那个“沉默的发动机”角色它不显眼但所有数据管道都依赖它可靠地工作。最后再分享一个小技巧无论项目多小都建议给请求层加上日志。每次请求记录时间、URL、状态码、耗时这样排查问题的时候才有据可循。很多看起来莫名其妙的故障翻日志之后会发现早有征兆。工具选得再好也得配合好的使用习惯这才是爬虫项目能长期健康运行的根本。
做电商爬虫这行时间久了你会发现真正决定一个采集项目能不能稳定跑下去的往往不是解析规则写得有多巧妙而是最底层的请求环节靠不靠谱。我自己用 xxxwww 这个轻量请求模块搭过好几套电商采集链路从商品列表到详情页再到价格库存监控说实话踩过的坑比写过的规则还多。这篇文章就把 xxxwww 在电商爬虫里的实际应用拆开讲清楚包括它到底承担什么角色、怎么配置连接与会话、如何配合解析和数据落地以及那些常规文档里根本不会写的高频问题。内容比较偏实战适合已经写过一点爬虫、但想把自己采集脚本做得更稳的读者。如果你只是刚接触爬虫也能跟着步骤跑通一套完整的采集管道后面再慢慢理解每个参数背后的原理。1. 先搞清楚 xxxwww 在电商爬虫里承担什么角色1.1 一条完整电商采集链路请求层为什么最关键大多数人聊爬虫注意力都在解析和反爬容易忽略一件事电商页面结构再复杂、验证逻辑再多最终都要落到“能不能稳定拿到 HTML 或 JSON”这个前提上。抓不到数据后面所有解析都是空中楼阁。一条典型的电商采集链路大概是这样的任务调度器把待采集的 URL 交给请求模块请求模块负责发起网络请求、处理 Cookie、跟随重定向、应对超时和临时封禁拿回响应之后再由解析模块抽取字段最后清洗落库。这里面的请求模块就是 xxxwww 的核心位置。之所以说它最关键是因为电商站点的请求特征很特殊。商品列表页和详情页动辄几百上千个字段一个页面里有大量图片和异步接口请求频率一高服务器的连接池、DNS 解析、TLS 握手这些环节都会成为瓶颈。xxxwww 在真实项目里帮我解决的就是把这些底层细节收敛成一个稳定可控的请求入口让上层业务只关心“给我这个 URL我拿到内容”。1.2 xxxwww 的定位把“拿到网页”这件事做扎实很多新手喜欢一上来就上 Scrapy 或者 Playwright其实早期阶段没必要。Scrapy 的学习成本和框架约束都不低Playwright 要起浏览器内存开销也大。电商采集的很多场景尤其是价格监控、库存变化、榜单更新本质上都是高频小请求一个轻量级的请求模块反而更合适。xxxwww 在我看来就是干这个的。它不替你解析页面也不替你管理任务队列而是把 HTTP 请求层做厚连接池复用、会话保持、超时控制、重试策略、请求头管理这些事它都给你留好了口子。你只需要告诉它“我要访问哪个地址、带什么参数、多久算超时”剩下的网络细节它来处理。我在项目里的习惯是把 xxxwww 再包一层做成项目自己的 fetch 函数。这样所有请求都走同一个入口统一打日志、统一加公共请求头、统一处理异常后面排查问题的时候特别方便。这个习惯让我少加了不少班。1.3 选型对比为什么不用重量级框架直接上这里不是否定重量级框架而是说场景要匹配。电商采集链路里如果任务量是每天几千个商品用 xxxwww 这种轻量模块就够了如果每天几百万级 URL那确实需要 Scrapy 的调度和去重能力。但大部分中小团队和个人项目远没到那个量级用轻量模块反而更灵活。我拿三个方案做对比大家感受一下方案上手成本资源占用灵活度适合场景xxxwww 自建管道低低高中小规模采集、监控类脚本Scrapy中高中中大规模分布式采集Playwright/Selenium低API友好很高中强交互页面、JS 渲染严重的站点选择 xxxwww 还有一个实际考虑它对环境要求低部署到一台小服务器上就能跑不像浏览器自动化那样动辄要 1G 以上内存。实测下来单机跑十几个采集任务CPU 和内存占用都很稳。这也意味着你可以把更多资源留给数据处理和存储环节。2. 动手前先想清楚这些事目标规则与会话模型2.1 先去看目标站点的爬虫协议别上来就怼这步看起来不起眼但其实非常重要。电商站点一般都会提供 robots.txt里面会明确哪些路径允许抓取、哪些不允许还经常有 Crawl-delay 字段告诉你请求间隔的建议值。合规采集的第一步就是尊重这些规则。我拿到一个电商目标之后会先手动访问一下站点把商品类目、列表页、详情页的 URL 规律摸清楚。同时确认数据是服务端渲染还是前端异步加载。如果页面内容要靠接口返回那 xxxwww 的主要请求对象就是那些 JSON 接口而不是 HTML 页面。这样定位清楚之后后面写规则才有方向。这里尤其要注意很多电商站点的分类筛选是带参数的 URL比如?page2sortprice。这种参数规律最好在浏览器里先点一遍把 URL 变化记录下来再在代码里动态拼参数。我写采集逻辑时很少硬编码 URL基本都是参数化拼接这样后续加类目、改排序只要改配置。2.2 连接池与会话保持的正确打开方式电商页面里有很多静态资源是同一个域名下的如果每次请求都重新建立 TCP 连接和 TLS 握手效率会低得离谱。xxxwww 在连接管理上做了连接池复用同一个 host 的连接可以重复使用大幅减少握手开销。我实际使用时的配置思路是创建一个全局的会话对象所有请求都通过这个会话发出。会话对象会帮我们自动管理 Cookie同时也复用底层连接。如果你每个请求都新建一个会话不仅 Cookie 断掉连接也没法复用性能差距非常明显。我试过用同一个会话连续抓取同一站点上百个商品页响应时间往往能稳定在 300ms 到 800ms 之间。如果每次请求都重新建连延迟直接翻倍。所以“一个会话走天下”是电商采集里特别值得养成的习惯。2.3 Header 与 Cookie 的细节像真实访客一样访问很多反爬策略的第一道关卡就是请求头检查。电商站点通常会校验 User-Agent、Referer、Accept-Language 这些字段。用 xxxwww 请求时建议把浏览器里常见的请求头完整带上。这里有个小细节Referer 字段特别容易被忽略但很多电商站点的图片和接口都会校验它。我通常会在请求模块里维护一份默认请求头不同场景再去覆盖。比如访问列表页时 Referer 设置为首页访问详情页时 Referer 设置为对应的列表页 URL。这样整个访问轨迹看起来更像真人操作。Cookie 这块就更重要了。首次访问电商站点服务器通常会下发一些标识用的 Cookie后续请求都要携带。用 xxxwww 的会话对象可以直接免去手动维护 Cookie 的麻烦但如果你的采集任务需要模拟登录那就得手动管理登录态和 Cookie 的更新时机。常见做法是把登录后的 Cookie 序列化保存到本地过期后再重新登录。3. 实操用 xxxwww 搭一套商品信息采集管道3.1 先把采集目标和字段模型定下来前面铺垫了那么多终于到动手环节。我习惯先定义清楚要什么字段再写请求代码这样可以避免后面反复改解析逻辑。比如我们要采集某个电商类目下的商品信息核心字段一般是商品 ID、标题、价格、月销量、库存状态、店铺名称、详情页 URL。这些字段定义好之后再确定数据结构。日常开发里我直接用字典列表跑通后再根据数据量决定写 CSV 还是入库。下面是一个最小可用的字段模型fields { product_id: , title: , price: 0.0, month_sales: 0, stock_status: , shop_name: , detail_url: , }这一步看着简单但对整个采集管道的稳定性影响很大。字段模型清晰了后面的解析、清洗、去重才能有条不紊。不要嫌这一步麻烦后期改字段可比前期定义字段痛苦多了。3.2 名单页请求与翻页先写一个能跑的循环接着进入核心请求环节。我们先用 xxxwww 请求榜单页拿到商品列表数据。为了方便理解我这里假设榜单页返回的是 JSON 数据这也是目前很多电商接口的常见形式。import xxxwww session xxxwww.Session() DEFAULT_HEADERS { User-Agent: Mozilla/5.0 ..., Accept: application/json, text/plain, */*, Referer: https://example.com/, } def fetch_list(page): url https://example.com/api/rank params { page: page, page_size: 50, sort: default, } resp session.get(url, headersDEFAULT_HEADERS, paramsparams, timeout(5, 15)) resp.raise_for_status() return resp.json()代码里我设置了 timeout而且是(5, 15)这种元组形式分别代表连接超时和读取超时。这是电商采集里很实用的配置方式连接超时短一点5 秒连不上就放弃读取超时长一点给服务器处理请求留足时间。跑通单页之后翻页逻辑就顺理成章了。要特别注意循环里的异常处理别让一个页面超时导致整个任务中断。我一般会给单页请求包一层异常捕获失败则记录日志后跳过同时统计失败次数连续失败超过阈值就主动终止任务。3.3 详情页请求批量取数据时要有点耐心列表页拿到的是商品 ID 和摘要信息详情页才是完整数据的来源。批量采集详情页时最忌讳的就是无脑 for 循环一口气请求完所有 URL。服务器不是傻子一秒几十个请求的节奏很容易触发风控。我用 xxxwww 跑详情页时会设置一个请求间隔通常在 0.5 到 2 秒之间随机波动。随机不是为了做坏事而是让请求节奏更接近真人操作降低对目标服务器的压力。这种对双方都友好的采集节奏才是长期能跑下去的关键。另外详情页返回的数据格式往往更复杂可能是嵌套的 JSON也可能是 HTML 里嵌着 JSON 数据。遇到后者我的做法是先用正则或者字符串查找把 JSON 块切出来再用解析库转成字典而不是对着 HTML 硬写选择器。这样代码更稳定因为页面结构可能变但内嵌的数据格式一般变化较小。import re import json from parsel import Selector def fetch_detail(product_id): url fhttps://example.com/product/{product_id} resp session.get(url, headersDEFAULT_HEADERS, timeout(5, 15)) html resp.text # 从页面里提取内嵌 JSON 数据块 match re.search(rwindow.__INITIAL_STATE__ ({.*?});, html) if match: return json.loads(match.group(1)) # 如果没找到 JSON 块退回 HTML 解析 selector Selector(texthtml) return { title: selector.css(h1.product-title::text).get(), price: selector.css(span.product-price::text).get(), }这段代码展示了两种解析策略的切换。实际项目里我经常是先试着取 JSON 块取不到再用 HTML 选择器兜底。多一层兜底代码就多一分健壮性。3.4 频率控制、重试与失败恢复让脚本能挂机跑一夜写采集脚本最怕什么最怕半夜脚本挂掉第二天起来一看跑了三小时全白跑。所以频率控制和失败恢复能力是衡量一个采集脚本是否合格的重要标准。频率控制方面除了前面说的随机间隔还可以加一个简单的分钟级限速。比如每分钟最多请求 30 次超过就休眠。这种限速逻辑用 xxxwww 也容易实现包一层计数判断就行。重试机制同样重要。网络抖动、服务器 5xx 错误这些都是不可避免的。我一般在请求函数里加一个重试装饰器对连接超时、读取超时和 5xx 状态码做最多 3 次重试。重试间隔采用递增策略比如第 1 次等 1 秒、第 2 次等 3 秒、第 3 次等 5 秒避免在服务器还没恢复时反复冲击。失败恢复方面我会把每批任务的进度实时写入一个任务表记录哪些商品 ID 已成功、哪些失败。重新跑的时候只补采失败的那部分就行。这个机制救过我很多次尤其当采集任务跑到一半被中断时不需要从头再来。3.5 数据清洗与落库采集的最后一步不是请求数据拿到手之后还有一道清洗的工序。电商数据里最常见的脏数据包括价格字段带货币符号、销量字段是“1万”这种中文格式、库存状态是空字符串。这些都需要在落库前统一处理。我的清洗逻辑一般分三步第一步类型转换把价格、销量转成数值类型第二步格式统一比如把“1万”转成 10000第三步去重同一个商品 ID 只保留最新记录。三步做完之后再决定存到 CSV 还是数据库。如果是个人小项目存 CSV 就够用简单直接。但如果要做长期监控和趋势分析建议落到 SQLite 或者 MySQL。我自己做过一套价格监控就是把每日价格写入 SQLite然后用一个简单查询看价格波动。数据量不大但胜在稳定跑几个月都没出过问题。4. 高频问题排查实录这些坑我替你先踩了4.1 请求被断开Connection Reset 怎么定位这是电商爬虫最经典的问题之一通常不是单一原因而是多个因素叠加。我遇到这种情况第一反应不是加代理而是先检查自己的请求频率。很多时候就是同一个 IP 请求太密集触发了服务端的连接保护。先把请求间隔拉长观察几分钟如果问题消失那就是频率问题。还有一种可能是 HTTP 版本问题。有些服务端对 HTTP/1.1 的 keep-alive 连接处理比较激进长连接空闲太久会被重置。解决方法是请求前设置 Connection 头部或者定期重建会话对象避免连接长时间空闲。我的排查顺序是请求频率 → 会话状态 → 请求头完整性 → 本地网络出口。按照这个顺序排查大部分 Connection Reset 都能找到原因。4.2 返回内容出现乱码或者大量空数据乱码问题大多是编码判断出错。很多站点在响应头里没有明确声明 charset或者在 HTML 的 meta 标签里才写明编码。xxxwww 拿到的响应内容需要先判断编码再解码不能直接按默认编码处理。我的办法是优先看响应头里的Content-Type如果没有 charset就解析 HTML 里的 meta 标签再用检测库识别编码。这套流程写成一个小函数基本上能覆盖绝大多数中文站点的编码问题。空数据的问题则复杂一些。接口返回 200 但 body 是空或者 JSON 解析出来是空列表一般是因为参数缺失、地区限制或者请求头里缺少某个认证信息。这时候别急着改代码先用浏览器手动请求同一个接口用开发者工具对比请求头差异通常很快能找到原因。4.3 采集到一半突然开始返回验证码页面这种情况说明你的请求节奏已经被目标站点标记了。最直接的处理是立刻降低频率让脚本暂停一段时间同时检查请求头、Cookie 是否有缺失。如果你已经大量请求了几千个页面建议换个出口 IP 再继续。但有几个合规提醒想多说一句不要尝试破解验证码不要去研究绕过风控的灰色技巧。电商爬虫的正道是控制合理频率、遵守站点规则、优先采集公开数据。作为采集技术的使用者我们对目标服务器的资源负载负有责任。保持克制反而能跑得更久。4.4 高频问题速查表现象可能原因处理建议Connection Reset请求频率过高或连接空闲超时降低频率、定期重建会话返回乱码编码识别错误自行检测并指定正确编码空数据/空列表参数缺失或地区限制对照浏览器请求排查参数突然出现验证码触发风控策略暂停采集、降低速度、检查请求头响应超时目标接口响应慢调大读取超时开启重试被限制访问IP 被短期限制暂停一段时间避免继续请求这张表我贴在自己的项目文档里每次脚本出问题就先查一遍能省下大量排查时间。5. 一点经验体会做了这么久的电商采集我越来越觉得稳定压倒一切。一个能稳定跑数据的轻量脚本比一个功能花哨但三天两头挂掉的框架实用得多。xxxwww 在我的项目里一直扮演着那个“沉默的发动机”角色它不显眼但所有数据管道都依赖它可靠地工作。最后再分享一个小技巧无论项目多小都建议给请求层加上日志。每次请求记录时间、URL、状态码、耗时这样排查问题的时候才有据可循。很多看起来莫名其妙的故障翻日志之后会发现早有征兆。工具选得再好也得配合好的使用习惯这才是爬虫项目能长期健康运行的根本。
