尧图网站建设 
简介速卖通数据爬取工具是一套基于自动化浏览器与GUI的轻量级爬虫源码面向跨境电商数据分析者、开发者及技术学习者帮助解决速卖通商品信息批量获取、关键词搜索与数据导出等需求。压缩包共6个文件以Python脚本为主包含三个核心模块控制逻辑、主功能、图形界面另有依赖说明与配置文件整体仅11KB结构精简易读。已有104人学习浏览适合作为爬虫入门与电商数据采集的参考实践。源码采用模块化设计control.py负责调度与参数处理main.py实现登录、cookie获取及多线程爬取ui.py提供可视化交互界面用户可自定义关键词与页面数抓取结果支持导出CSV等格式便于后续分析。对于希望理解自动化登录、多线程抓取及PyQt界面搭建的读者这份源码提供了完整可运行的示例同时也包含开源合规提醒适用于学习研究场景。 做跨境电商选品或者运营盯竞品的朋友应该都体会过那种感觉想在速卖通上拉一批竞品数据做分析手动一页页翻、一个个复制粘贴弄到后半夜眼睛都快瞎了数据还不一定能整理利索。市面上倒是有现成的采集软件但要么贵的离谱要么采集字段固定死、自由度低用着总觉得隔靴搔痒。这种情况下自己动手写一个速卖通数据爬取工具就成了很自然的想法既能完全按自己的需求定制字段又能把整个采集流程自动化还能省下一笔不小的工具订阅费。这篇文章就把我做这个工具的完整思路、核心代码逻辑、以及调试过程中踩进去又爬出来的那些坑一次性说清楚。1. 为什么非要自己写采集器现成方案的不如意先说结论如果你只是偶尔采集几十条商品数据做参考直接用现成的网页版采集工具或者付费插件就够了别浪费时间自己造轮子。但如果你需要长期、批量、定制化地采集数据那自己写一个绝对值得。我之前仔细研究过几款市面上的采集器它们大致分两类。一类是浏览器插件形式的操作确实简单打开速卖通页面点一下就能抓当前页但问题在于字段是预设好的想额外抓个SKU销量、店铺粉丝数什么的往往得提需求等版本更新而且采集量一大就频繁遇到验证码弹窗基本处于半瘫痪状态另一类是云端SaaS采集平台稳定性和速度确实好一些但收费是按采集条数算的商品详情页这种字段多的页面一条就要不少钱月结下来费用不低。除了成本和灵活度的考量还有一个更现实的问题数据的所有权和可控性。用平台采集数据始终在别人服务器上你导出之后还要再清洗一遍格式自己写爬虫数据直接落本地数据库想怎么结构化就怎么结构化想什么时候增量更新就什么时候增量更新整个流程完全由自己掌控。所以我的判断是如果只是尝鲜用现成工具没问题如果把它当成一个长期的数据分析基础设施来做自己用Python写一套采集器后面接上选品分析、价格监控、关键词热度分析这些应用才是正道。2. 采集器全局设计先定框架再写代码别上来就抠细节写爬虫最大的忌讳就是一上来就写请求代码结果爬到一半发现字段结构理解错了或者登录态失效了整个流程崩掉重来。我习惯先花一两个小时把整体架构和数据结构想清楚。2.1 两个核心模块采集引擎与数据模型我的速卖通采集器分两层。上层是采集引擎负责请求调度、登录态管理、反爬规避、错误重试下层是数据模型定义了商品需要保存哪些字段以及这些字段在页面里怎么解析。数据模型是最先确定的因为它决定了后面所有解析逻辑怎么写。以采集商品列表页和详情页为例我的核心字段表长这样字段名类型来源说明product_idstring列表页/详情页URL商品唯一标识去重用titlestring列表页/详情页商品标题price_min / price_maxfloat列表页/详情页价格区间有的SKU价格不同sales_countint列表页销量数据判断爆款核心指标ratingfloat详情页评分review_countint详情页评价数seller_namestring详情页店铺名image_urlslist详情页商品主图和详情图sku_infolist详情页SKU选项和价格detail_htmlstring详情页完整详情HTML备用定义好数据模型之后采集引擎的架构就围绕这个数据模型来设计。整个流程是先从列表页拿到搜索关键词下的所有商品URL再逐个请求详情页解析出完整字段最后写入数据库。为了保证爬取效率我用的是Python的concurrent.futures线程池做并发请求线程数控制在8-16之间太低了速度上不去太高了容易被封IP。2.2 请求流程与状态管理模拟真实用户操作节奏采集流程的状态管理非常关键。速卖通这类跨境电商平台对访问频率和模式很敏感如果请求间隔太均匀、频率太高很容易触发风控。我的做法是用一个请求队列每个请求在发出前都会经过一个调度器调度器会根据当前IP的请求频率和成功率动态调整下一次请求的延迟。这里的核心逻辑是不要让请求在时间轴上均匀分布而是模拟真实用户的操作节奏——有搜索、有浏览、有停留偶尔还有中断。我设置的基础延迟在2到5秒之间随机浮动然后根据连续请求的成功率动态调整一旦检测到连续失败或验证码出现就自动拉大延迟并切换代理。3. 登录态与Cookie管理速卖通爬虫最容易翻车的一环速卖通的数据采集里登录态管理是让很多人头疼的问题。如果你不登录也能搜到商品、看到基本价格但销量数据、评价数据、SKU价格这些都是拿不全的而且未登录状态下的反爬规则更严格很容易弹验证码。3.1 Cookie的获取与有效期管理我的方案是使用一个固定的买家账号通过手动在浏览器里完成一次登录然后从浏览器开发者工具里复制出完整的Cookie字符串放到配置文件中。爬虫启动时读取Cookie并附加到每个请求上。这个方法很简单但要注意两点Cookie是有时效的。速卖通的登录Cookie一般能维持几天到几周不等取决于账号活跃度。我的做法是写一个Cookie有效性检测函数——每隔一段时间请求一次个人中心页如果返回的页面里没有账号名就判定Cookie失效需要重新登录并更新配置文件。不要在上千个请求里同时使用同一个Cookie。速卖通对单个账号的并发请求数有限制如果同个账号同时有几十个并发请求穿行账号很容易被标记为异常轻则强制登出重则触发验证码关卡。我是把所有请求都串行化或低并发化并且用一个共享的Cookie管理器统一维护保证同一时间只有一个会话在使用。3.2 登录态过期后的自动恢复机制为了尽量做到无人值守我在采集引擎里加了一个自动化恢复机制一旦检测到Cookie失效就通过Selenium重新走一遍登录流程——打开登录页填入账号密码通过滑块验证如果触发然后从浏览器上下文里提取新的Cookie并回写配置。这个流程虽然慢但作为一个兜底方案能让你睡觉的时候采集器不至于卡死。这里有个细节Selenium登录后会拿到一组新的Cookie但如果你只是把浏览器里的Cookie复制出来填到requests里有可能部分字段无效。更稳妥的做法是让Selenium在登录完成后直接用seleniumwire或browser_cookie3去抓取浏览器完整的Cookie然后存成requests可用的格式。我实测下来这一步能减少很大一部分“登录了但还是提示未登录”的诡异问题。4. 列表页与详情页解析数据抽取的核心实战4.1 列表页先搞定翻页和商品ID提取速卖通的搜索结果页是典型的无限滚动页面但它的请求其实是一个普通的分页接口。这一点很关键——你不需要用Selenium模拟滚动直接改URL参数就能翻页。速卖通搜索页的URL里有个page参数?page1是第一页page2是第二页以此类推。用requests直接请求这个URL返回的HTML里包含了所有商品卡片。解析时我用parsel也就是Scrapy打包出来的解析库做选择器提取因为它是CSS选择器和XPath都支持比纯正则要好维护得多。提取商品ID的正则我是这样写的import re def extract_product_ids(page_html): # 速卖通的商品链接形如 https://www.aliexpress.com/item/1005001234567890.html pattern re.compile(r/item/(\d)\.html) product_ids re.findall(pattern, page_html) # 去重且保持顺序 seen set() unique_ids [] for pid in product_ids: if pid not in seen: seen.add(pid) unique_ids.append(pid) return unique_ids这里有个坑一个列表页HTML里常常会混入推荐位、广告位商品的ID这些链接和自然搜索结果混在一起如果你不去重采集数据会有很多杂音。我的做法是对同一个关键词的前3页都抓一遍把商品ID汇总去重后统一进入详情页采集队列这样能过滤掉相当一部分重复的推荐商品。4.2 详情页关键字段藏在JSON里进入详情页后页面结构要复杂得多。标题、价格、评价数这些数据散布在多个DOM节点里而且不同商品模板的结构会有细微差异。为了稳定解析我使用了两层策略第一层先直接从HTML的script标签里找window.runParams或window._dida_config_这类内嵌的JSON数据。速卖通页面和很多电商网站一样首次加载时就把商品的核心数据塞进了页面的全局变量或__NEXT_DATA__结构的脚本里这部分数据是结构化最好的直接json.loads就能拿到完整字段。import json import re def extract_page_json_data(page_html): # 页面里有类似 window.runParams {...} 的数据 pattern re.compile(rwindow\.runParams\s*\s*({.*?});, re.S) match pattern.search(page_html) if not match: return None try: return json.loads(match.group(1)) except json.JSONDecodeError: return None第二层如果第一层没找到或者字段不完整就退回到常规的CSS/XPath解析从DOM节点里提取。这一层需要针对标题、价格、评价数各写一个选择器还要兼容商品标题可能出现在h1、a、title等不同位置的情况。实际跑下来两者大概覆盖了95%的字段需求。剩下5%是那些特殊SKU结构复杂、模板异常的商品直接在日志里记录并跳过保证整个采集任务不会因为这些垃圾数据而中断。4.3 SKU信息的处理比想象中要费劲很多商品不是只有一个价格而是有一堆SKU选项比如颜色、尺码、规格每个SKU的价格和库存都不一样。如果采集数据只拿一个最低价对于选品分析来说误差太大。所以我的详情页解析里专门写了SKU提取逻辑。速卖通的SKU数据通常也隐藏在内嵌JSON里结构大概是skuModule下面有一份productSKUPropertyList里面每个属性项再关联价格和库存。拿到这份数据后需要做一个映射处理把SKU名称和价格、库存对应起来。这个过程的关键是注意区分不同货币单位速卖通页面展示价格时默认美元但如果你在采集时切换了页面底部的货币选项JSON里的价格字段可能就变成了其他币种入库前需要做一次币种归一化否则后续价格对比分析就全乱了。5. 反爬对抗与请求频率控制别让你的IP成为炮灰这是整个工具里最需要耐心琢磨的部分。直接说结论速卖通的反爬策略重点不是你怎么伪造Header而是你的请求行为像不像真人。5.1 请求头伪装少了浏览器指纹照样被拦现在所有主流网站的验头环节都不仅看User-Agent还会看Accept、Accept-Language、Sec-Fetch-Mode、Sec-Fetch-Site、Upgrade-Insecure-Requests这些。如果你只伪造一个User-Agent而不关心其他请求头那基本第一批请求就会被拦下。我用来做请求头保证稳定的一套BaseHeader是这样的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/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: en-US,en;q0.9,zh-CN;q0.8,zh;q0.7, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Upgrade-Insecure-Requests: 1, Sec-Fetch-Dest: document, Sec-Fetch-Mode: navigate, Sec-Fetch-Site: same-origin, Sec-Fetch-User: ?1, }注意Accept-Language别写成纯中文因为速卖通默认是国际站英文请求头更贴近真实海外用户的浏览习惯。另外重要一点把Keep-Alive打开让requests.Session复用底层的TCP连接这样不仅请求速度更快行为上更像是同一个浏览器的持续访问不容易被当作全新会话。5.2 IP代理池没有它采集量一大必死当你每天要采集上万条商品数据时单个IP根本扛不住几乎100%会触发风控。我的处理方案是维护一个IP代理池每发一个请求就随机换一个出口IP。代理池的来源有两个渠道。一个是商业代理服务商这个稳定性最好但成本也高另一个是自建的低成本代理池——用一些海外VPS搭简易的HTTP代理配合免费的代理列表定期清洗可用IP。考虑到速卖通的面向市场主要是海外用户代理IP的国别也很重要最好混合多个国家的IP避免总是同一个国家的IP刷同一个关键词这样风控特征更明显。代理池代码的骨架是这样import random import requests class ProxyPool: def __init__(self, proxies): self.proxies proxies def get_random_proxy(self): return random.choice(self.proxies) def test_proxy(self, proxy): try: response requests.get( https://www.aliexpress.com, proxies{http: proxy, https: proxy}, timeout5 ) return response.status_code 200 except Exception: return False # 使用示例 pool ProxyPool([http://ip1:port, http://ip2:port]) proxy pool.get_random_proxy() session.proxies {http: proxy, https: proxy}每次请求前做一个快速连通性测试是有必要的虽然会增加一点耗时但能显著减少因为坏代理导致的超时错误和失败重试整体效率反而更高。5.3 限速与退避策略宁可慢一点不能被封我在调度器里加了一套自适应限速逻辑。基础规则是同一个关键词的连续请求间隔至少3秒不同关键词之间间隔至少1秒当一个IP连续失败3次时自动将该IP从池子里剔除当整个任务失败率达到10%时全局限速拉长到10秒以上同时触发一个冷却状态等待5分钟再恢复。这套策略跑下来一个包含2000个商品ID的采集任务在8个并发线程下大约需要40到60分钟完成速度不算特别快但胜在稳定——整个过程中几乎不会触发验证码。如果你追求更快的采集速度我的建议不是加并发线程而是改用分布式的多机方案每台机器用不同的账号和IP段这样风险分散效果好得多。6. 避坑实录我在这几个地方折腾到怀疑人生6.1 动静态资源拼接问题采集详情页时你会发现图片和详情富文本里的链接很多是相对路径比如/media/xxx.jpg如果不拼接域名直接用存到数据库里的图片链接就是废的。这个问题看起来小但会影响后面所有用数据的应用场景。我的处理是在存储阶段统一判断如果是相对路径就拼上https:前缀。6.2 商品数据里的时间戳计量单位速卖通有些页面里时间的表示方式是Unix时间戳但注意它可能是毫秒级的也有的字段是秒级的。解析时如果不统一排序就会出错。我踩过一次坑——拿评价时间戳排序时发现排序结果完全乱掉最后才发现有的商品接口返回的是13位毫秒级时间戳有的是10位秒级。后来我写了一个统一转换函数先判断位数再转换彻底解决这个问题。6.3 从详情页翻回列表页的坑每个商品详情页底部会有一个“You may also like”的推荐模块里面的链接和正常商品链接长得很像也是/item/数字.html的格式。如果你从详情页也跑一个提取商品ID的逻辑就会把这堆推荐商品也抓进来。我最初的采集器是列表页和详情页各跑一遍提取逻辑结果数据量暴增了三倍多里面还混着大量相似度极高的推荐产品。这个问题让我意识到必须在采集链路里明确指定哪些页面是数据源哪些页面的链接只能作为补充参考不能混为一谈。6.4 时区、价格符号与字段格式清洗入库前一定要做字段级清洗。价格字段明文里可能带着$、€或US $字样需要统一转成float评价数可能有“1,234”这样的千分位格式也需要去掉逗号。这些清洗逻辑虽然琐碎但如果不上心后面做数据透视表的时候各种格式错误会让你崩溃。6.5 本地调试一定要用独立测试账号正式跑大规模采集之前建议先用一个独立的测试账号、小范围关键词、低并发验证整个流程。我一开始为了省事直接用主力买家账号测试高并发采集结果不到十分钟账号就被限流了搜索页触发滑块验证手动解封折腾了半个多小时。记住爬虫调试阶段的试错成本一定控制在测试账号上别拿主力账号当小白鼠。7. 数据落库与后续分析方向采集到的数据如果只是堆在JSON文件里价值就少了一半。我的做法是把数据同步到MySQL和ES两套存储MySQL存结构化字段用于日常的表格分析和报表生成ES存全文数据方便做关键词搜索和商品匹配。建表时建议给product_id一个唯一索引这个字段是从采集开始就一直维护的核心主键后续增量和全量更新的数据都靠它老去重。另外crawl_date字段记录采集日期这样你就能分析同一个商品在不同时间点的价格变化、销量增长趋势这可是手动采集完全做不到的事情。基于这套数据结构我已经延展出了几个分析模型爆品预测根据销量增速和评论增长速度排序、竞品价格监控跟踪指定竞品清单每天的价格变动、关键词词频分析统计搜索词下Top商品标题里的高频词。这些模型对于选品和运营决策非常有价值而且因为数据是自己采集的细节和维度完全可控不受第三方工具的字段限制。8. 源码获取与使用建议整个工具的源码结构大致是aliexpress_spider/ ├── config.py # 配置文件Cookie、代理、数据库连接 ├── spider/ │ ├── engine.py # 采集引擎请求调度、线程池、重试逻辑 │ ├── parser.py # 页面解析列表页、详情页的数据提取 │ └── taobao_login.py # Cookie自动恢复Selenium ├── storage/ │ └── db.py # MySQL/ES存储层 ├── utils/ │ ├── clean.py # 数据清洗工具 │ └── proxy_pool.py # 代理池管理 └── main.py # 入口读取关键词触发采集任务下载后使用之前有几个提醒先修改config.py里的Cookie、代理和数据库连接信息不要直接用默认值跑。先用一个冷门关键词、少量页数做测试确认流程稳定后再逐步扩大采集范围。注意不要频繁、大规模地采集同一类目下的数据给平台服务器一点缓冲也给自己账号留一点安全空间。数据使用务必遵守法律法规和平台服务条款仅用于个人学习研究或合法商业分析不用于任何非法用途。我个人在实际使用中的体会是这套工具最大的价值不是省了多少时间而是让我有了稳定的数据获取能力这远比东拼西凑的第三方数据源可靠得多。后续如果你想扩展可以考虑加上速卖通买家秀数据的采集、评论情感分析、以及结合关键词搜索量做蓝海词挖掘这些我都在逐步完善中等到跑通了再出来写第二篇分享。本文还有配套的精品资源点击获取 自建速卖通爬虫采集器：Python打造跨境电商数据采集工具的完整指南
简介速卖通数据爬取工具是一套基于自动化浏览器与GUI的轻量级爬虫源码面向跨境电商数据分析者、开发者及技术学习者帮助解决速卖通商品信息批量获取、关键词搜索与数据导出等需求。压缩包共6个文件以Python脚本为主包含三个核心模块控制逻辑、主功能、图形界面另有依赖说明与配置文件整体仅11KB结构精简易读。已有104人学习浏览适合作为爬虫入门与电商数据采集的参考实践。源码采用模块化设计control.py负责调度与参数处理main.py实现登录、cookie获取及多线程爬取ui.py提供可视化交互界面用户可自定义关键词与页面数抓取结果支持导出CSV等格式便于后续分析。对于希望理解自动化登录、多线程抓取及PyQt界面搭建的读者这份源码提供了完整可运行的示例同时也包含开源合规提醒适用于学习研究场景。 做跨境电商选品或者运营盯竞品的朋友应该都体会过那种感觉想在速卖通上拉一批竞品数据做分析手动一页页翻、一个个复制粘贴弄到后半夜眼睛都快瞎了数据还不一定能整理利索。市面上倒是有现成的采集软件但要么贵的离谱要么采集字段固定死、自由度低用着总觉得隔靴搔痒。这种情况下自己动手写一个速卖通数据爬取工具就成了很自然的想法既能完全按自己的需求定制字段又能把整个采集流程自动化还能省下一笔不小的工具订阅费。这篇文章就把我做这个工具的完整思路、核心代码逻辑、以及调试过程中踩进去又爬出来的那些坑一次性说清楚。1. 为什么非要自己写采集器现成方案的不如意先说结论如果你只是偶尔采集几十条商品数据做参考直接用现成的网页版采集工具或者付费插件就够了别浪费时间自己造轮子。但如果你需要长期、批量、定制化地采集数据那自己写一个绝对值得。我之前仔细研究过几款市面上的采集器它们大致分两类。一类是浏览器插件形式的操作确实简单打开速卖通页面点一下就能抓当前页但问题在于字段是预设好的想额外抓个SKU销量、店铺粉丝数什么的往往得提需求等版本更新而且采集量一大就频繁遇到验证码弹窗基本处于半瘫痪状态另一类是云端SaaS采集平台稳定性和速度确实好一些但收费是按采集条数算的商品详情页这种字段多的页面一条就要不少钱月结下来费用不低。除了成本和灵活度的考量还有一个更现实的问题数据的所有权和可控性。用平台采集数据始终在别人服务器上你导出之后还要再清洗一遍格式自己写爬虫数据直接落本地数据库想怎么结构化就怎么结构化想什么时候增量更新就什么时候增量更新整个流程完全由自己掌控。所以我的判断是如果只是尝鲜用现成工具没问题如果把它当成一个长期的数据分析基础设施来做自己用Python写一套采集器后面接上选品分析、价格监控、关键词热度分析这些应用才是正道。2. 采集器全局设计先定框架再写代码别上来就抠细节写爬虫最大的忌讳就是一上来就写请求代码结果爬到一半发现字段结构理解错了或者登录态失效了整个流程崩掉重来。我习惯先花一两个小时把整体架构和数据结构想清楚。2.1 两个核心模块采集引擎与数据模型我的速卖通采集器分两层。上层是采集引擎负责请求调度、登录态管理、反爬规避、错误重试下层是数据模型定义了商品需要保存哪些字段以及这些字段在页面里怎么解析。数据模型是最先确定的因为它决定了后面所有解析逻辑怎么写。以采集商品列表页和详情页为例我的核心字段表长这样字段名类型来源说明product_idstring列表页/详情页URL商品唯一标识去重用titlestring列表页/详情页商品标题price_min / price_maxfloat列表页/详情页价格区间有的SKU价格不同sales_countint列表页销量数据判断爆款核心指标ratingfloat详情页评分review_countint详情页评价数seller_namestring详情页店铺名image_urlslist详情页商品主图和详情图sku_infolist详情页SKU选项和价格detail_htmlstring详情页完整详情HTML备用定义好数据模型之后采集引擎的架构就围绕这个数据模型来设计。整个流程是先从列表页拿到搜索关键词下的所有商品URL再逐个请求详情页解析出完整字段最后写入数据库。为了保证爬取效率我用的是Python的concurrent.futures线程池做并发请求线程数控制在8-16之间太低了速度上不去太高了容易被封IP。2.2 请求流程与状态管理模拟真实用户操作节奏采集流程的状态管理非常关键。速卖通这类跨境电商平台对访问频率和模式很敏感如果请求间隔太均匀、频率太高很容易触发风控。我的做法是用一个请求队列每个请求在发出前都会经过一个调度器调度器会根据当前IP的请求频率和成功率动态调整下一次请求的延迟。这里的核心逻辑是不要让请求在时间轴上均匀分布而是模拟真实用户的操作节奏——有搜索、有浏览、有停留偶尔还有中断。我设置的基础延迟在2到5秒之间随机浮动然后根据连续请求的成功率动态调整一旦检测到连续失败或验证码出现就自动拉大延迟并切换代理。3. 登录态与Cookie管理速卖通爬虫最容易翻车的一环速卖通的数据采集里登录态管理是让很多人头疼的问题。如果你不登录也能搜到商品、看到基本价格但销量数据、评价数据、SKU价格这些都是拿不全的而且未登录状态下的反爬规则更严格很容易弹验证码。3.1 Cookie的获取与有效期管理我的方案是使用一个固定的买家账号通过手动在浏览器里完成一次登录然后从浏览器开发者工具里复制出完整的Cookie字符串放到配置文件中。爬虫启动时读取Cookie并附加到每个请求上。这个方法很简单但要注意两点Cookie是有时效的。速卖通的登录Cookie一般能维持几天到几周不等取决于账号活跃度。我的做法是写一个Cookie有效性检测函数——每隔一段时间请求一次个人中心页如果返回的页面里没有账号名就判定Cookie失效需要重新登录并更新配置文件。不要在上千个请求里同时使用同一个Cookie。速卖通对单个账号的并发请求数有限制如果同个账号同时有几十个并发请求穿行账号很容易被标记为异常轻则强制登出重则触发验证码关卡。我是把所有请求都串行化或低并发化并且用一个共享的Cookie管理器统一维护保证同一时间只有一个会话在使用。3.2 登录态过期后的自动恢复机制为了尽量做到无人值守我在采集引擎里加了一个自动化恢复机制一旦检测到Cookie失效就通过Selenium重新走一遍登录流程——打开登录页填入账号密码通过滑块验证如果触发然后从浏览器上下文里提取新的Cookie并回写配置。这个流程虽然慢但作为一个兜底方案能让你睡觉的时候采集器不至于卡死。这里有个细节Selenium登录后会拿到一组新的Cookie但如果你只是把浏览器里的Cookie复制出来填到requests里有可能部分字段无效。更稳妥的做法是让Selenium在登录完成后直接用seleniumwire或browser_cookie3去抓取浏览器完整的Cookie然后存成requests可用的格式。我实测下来这一步能减少很大一部分“登录了但还是提示未登录”的诡异问题。4. 列表页与详情页解析数据抽取的核心实战4.1 列表页先搞定翻页和商品ID提取速卖通的搜索结果页是典型的无限滚动页面但它的请求其实是一个普通的分页接口。这一点很关键——你不需要用Selenium模拟滚动直接改URL参数就能翻页。速卖通搜索页的URL里有个page参数?page1是第一页page2是第二页以此类推。用requests直接请求这个URL返回的HTML里包含了所有商品卡片。解析时我用parsel也就是Scrapy打包出来的解析库做选择器提取因为它是CSS选择器和XPath都支持比纯正则要好维护得多。提取商品ID的正则我是这样写的import re def extract_product_ids(page_html): # 速卖通的商品链接形如 https://www.aliexpress.com/item/1005001234567890.html pattern re.compile(r/item/(\d)\.html) product_ids re.findall(pattern, page_html) # 去重且保持顺序 seen set() unique_ids [] for pid in product_ids: if pid not in seen: seen.add(pid) unique_ids.append(pid) return unique_ids这里有个坑一个列表页HTML里常常会混入推荐位、广告位商品的ID这些链接和自然搜索结果混在一起如果你不去重采集数据会有很多杂音。我的做法是对同一个关键词的前3页都抓一遍把商品ID汇总去重后统一进入详情页采集队列这样能过滤掉相当一部分重复的推荐商品。4.2 详情页关键字段藏在JSON里进入详情页后页面结构要复杂得多。标题、价格、评价数这些数据散布在多个DOM节点里而且不同商品模板的结构会有细微差异。为了稳定解析我使用了两层策略第一层先直接从HTML的script标签里找window.runParams或window._dida_config_这类内嵌的JSON数据。速卖通页面和很多电商网站一样首次加载时就把商品的核心数据塞进了页面的全局变量或__NEXT_DATA__结构的脚本里这部分数据是结构化最好的直接json.loads就能拿到完整字段。import json import re def extract_page_json_data(page_html): # 页面里有类似 window.runParams {...} 的数据 pattern re.compile(rwindow\.runParams\s*\s*({.*?});, re.S) match pattern.search(page_html) if not match: return None try: return json.loads(match.group(1)) except json.JSONDecodeError: return None第二层如果第一层没找到或者字段不完整就退回到常规的CSS/XPath解析从DOM节点里提取。这一层需要针对标题、价格、评价数各写一个选择器还要兼容商品标题可能出现在h1、a、title等不同位置的情况。实际跑下来两者大概覆盖了95%的字段需求。剩下5%是那些特殊SKU结构复杂、模板异常的商品直接在日志里记录并跳过保证整个采集任务不会因为这些垃圾数据而中断。4.3 SKU信息的处理比想象中要费劲很多商品不是只有一个价格而是有一堆SKU选项比如颜色、尺码、规格每个SKU的价格和库存都不一样。如果采集数据只拿一个最低价对于选品分析来说误差太大。所以我的详情页解析里专门写了SKU提取逻辑。速卖通的SKU数据通常也隐藏在内嵌JSON里结构大概是skuModule下面有一份productSKUPropertyList里面每个属性项再关联价格和库存。拿到这份数据后需要做一个映射处理把SKU名称和价格、库存对应起来。这个过程的关键是注意区分不同货币单位速卖通页面展示价格时默认美元但如果你在采集时切换了页面底部的货币选项JSON里的价格字段可能就变成了其他币种入库前需要做一次币种归一化否则后续价格对比分析就全乱了。5. 反爬对抗与请求频率控制别让你的IP成为炮灰这是整个工具里最需要耐心琢磨的部分。直接说结论速卖通的反爬策略重点不是你怎么伪造Header而是你的请求行为像不像真人。5.1 请求头伪装少了浏览器指纹照样被拦现在所有主流网站的验头环节都不仅看User-Agent还会看Accept、Accept-Language、Sec-Fetch-Mode、Sec-Fetch-Site、Upgrade-Insecure-Requests这些。如果你只伪造一个User-Agent而不关心其他请求头那基本第一批请求就会被拦下。我用来做请求头保证稳定的一套BaseHeader是这样的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/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: en-US,en;q0.9,zh-CN;q0.8,zh;q0.7, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Upgrade-Insecure-Requests: 1, Sec-Fetch-Dest: document, Sec-Fetch-Mode: navigate, Sec-Fetch-Site: same-origin, Sec-Fetch-User: ?1, }注意Accept-Language别写成纯中文因为速卖通默认是国际站英文请求头更贴近真实海外用户的浏览习惯。另外重要一点把Keep-Alive打开让requests.Session复用底层的TCP连接这样不仅请求速度更快行为上更像是同一个浏览器的持续访问不容易被当作全新会话。5.2 IP代理池没有它采集量一大必死当你每天要采集上万条商品数据时单个IP根本扛不住几乎100%会触发风控。我的处理方案是维护一个IP代理池每发一个请求就随机换一个出口IP。代理池的来源有两个渠道。一个是商业代理服务商这个稳定性最好但成本也高另一个是自建的低成本代理池——用一些海外VPS搭简易的HTTP代理配合免费的代理列表定期清洗可用IP。考虑到速卖通的面向市场主要是海外用户代理IP的国别也很重要最好混合多个国家的IP避免总是同一个国家的IP刷同一个关键词这样风控特征更明显。代理池代码的骨架是这样import random import requests class ProxyPool: def __init__(self, proxies): self.proxies proxies def get_random_proxy(self): return random.choice(self.proxies) def test_proxy(self, proxy): try: response requests.get( https://www.aliexpress.com, proxies{http: proxy, https: proxy}, timeout5 ) return response.status_code 200 except Exception: return False # 使用示例 pool ProxyPool([http://ip1:port, http://ip2:port]) proxy pool.get_random_proxy() session.proxies {http: proxy, https: proxy}每次请求前做一个快速连通性测试是有必要的虽然会增加一点耗时但能显著减少因为坏代理导致的超时错误和失败重试整体效率反而更高。5.3 限速与退避策略宁可慢一点不能被封我在调度器里加了一套自适应限速逻辑。基础规则是同一个关键词的连续请求间隔至少3秒不同关键词之间间隔至少1秒当一个IP连续失败3次时自动将该IP从池子里剔除当整个任务失败率达到10%时全局限速拉长到10秒以上同时触发一个冷却状态等待5分钟再恢复。这套策略跑下来一个包含2000个商品ID的采集任务在8个并发线程下大约需要40到60分钟完成速度不算特别快但胜在稳定——整个过程中几乎不会触发验证码。如果你追求更快的采集速度我的建议不是加并发线程而是改用分布式的多机方案每台机器用不同的账号和IP段这样风险分散效果好得多。6. 避坑实录我在这几个地方折腾到怀疑人生6.1 动静态资源拼接问题采集详情页时你会发现图片和详情富文本里的链接很多是相对路径比如/media/xxx.jpg如果不拼接域名直接用存到数据库里的图片链接就是废的。这个问题看起来小但会影响后面所有用数据的应用场景。我的处理是在存储阶段统一判断如果是相对路径就拼上https:前缀。6.2 商品数据里的时间戳计量单位速卖通有些页面里时间的表示方式是Unix时间戳但注意它可能是毫秒级的也有的字段是秒级的。解析时如果不统一排序就会出错。我踩过一次坑——拿评价时间戳排序时发现排序结果完全乱掉最后才发现有的商品接口返回的是13位毫秒级时间戳有的是10位秒级。后来我写了一个统一转换函数先判断位数再转换彻底解决这个问题。6.3 从详情页翻回列表页的坑每个商品详情页底部会有一个“You may also like”的推荐模块里面的链接和正常商品链接长得很像也是/item/数字.html的格式。如果你从详情页也跑一个提取商品ID的逻辑就会把这堆推荐商品也抓进来。我最初的采集器是列表页和详情页各跑一遍提取逻辑结果数据量暴增了三倍多里面还混着大量相似度极高的推荐产品。这个问题让我意识到必须在采集链路里明确指定哪些页面是数据源哪些页面的链接只能作为补充参考不能混为一谈。6.4 时区、价格符号与字段格式清洗入库前一定要做字段级清洗。价格字段明文里可能带着$、€或US $字样需要统一转成float评价数可能有“1,234”这样的千分位格式也需要去掉逗号。这些清洗逻辑虽然琐碎但如果不上心后面做数据透视表的时候各种格式错误会让你崩溃。6.5 本地调试一定要用独立测试账号正式跑大规模采集之前建议先用一个独立的测试账号、小范围关键词、低并发验证整个流程。我一开始为了省事直接用主力买家账号测试高并发采集结果不到十分钟账号就被限流了搜索页触发滑块验证手动解封折腾了半个多小时。记住爬虫调试阶段的试错成本一定控制在测试账号上别拿主力账号当小白鼠。7. 数据落库与后续分析方向采集到的数据如果只是堆在JSON文件里价值就少了一半。我的做法是把数据同步到MySQL和ES两套存储MySQL存结构化字段用于日常的表格分析和报表生成ES存全文数据方便做关键词搜索和商品匹配。建表时建议给product_id一个唯一索引这个字段是从采集开始就一直维护的核心主键后续增量和全量更新的数据都靠它老去重。另外crawl_date字段记录采集日期这样你就能分析同一个商品在不同时间点的价格变化、销量增长趋势这可是手动采集完全做不到的事情。基于这套数据结构我已经延展出了几个分析模型爆品预测根据销量增速和评论增长速度排序、竞品价格监控跟踪指定竞品清单每天的价格变动、关键词词频分析统计搜索词下Top商品标题里的高频词。这些模型对于选品和运营决策非常有价值而且因为数据是自己采集的细节和维度完全可控不受第三方工具的字段限制。8. 源码获取与使用建议整个工具的源码结构大致是aliexpress_spider/ ├── config.py # 配置文件Cookie、代理、数据库连接 ├── spider/ │ ├── engine.py # 采集引擎请求调度、线程池、重试逻辑 │ ├── parser.py # 页面解析列表页、详情页的数据提取 │ └── taobao_login.py # Cookie自动恢复Selenium ├── storage/ │ └── db.py # MySQL/ES存储层 ├── utils/ │ ├── clean.py # 数据清洗工具 │ └── proxy_pool.py # 代理池管理 └── main.py # 入口读取关键词触发采集任务下载后使用之前有几个提醒先修改config.py里的Cookie、代理和数据库连接信息不要直接用默认值跑。先用一个冷门关键词、少量页数做测试确认流程稳定后再逐步扩大采集范围。注意不要频繁、大规模地采集同一类目下的数据给平台服务器一点缓冲也给自己账号留一点安全空间。数据使用务必遵守法律法规和平台服务条款仅用于个人学习研究或合法商业分析不用于任何非法用途。我个人在实际使用中的体会是这套工具最大的价值不是省了多少时间而是让我有了稳定的数据获取能力这远比东拼西凑的第三方数据源可靠得多。后续如果你想扩展可以考虑加上速卖通买家秀数据的采集、评论情感分析、以及结合关键词搜索量做蓝海词挖掘这些我都在逐步完善中等到跑通了再出来写第二篇分享。本文还有配套的精品资源点击获取