简介：直接运行就能抓取淘宝、京东、拼多多三家平台的店铺公开基础数据，包括店铺名、主营类目、开店时间、粉丝数量、在售商品数、DSR动态评分等结构化字段。整套工具基于Selenium驱动真实浏览器，绕过简单反爬机制，不调用任何第三方API，也不需要账号登录或授权——通过GetCookie.py手动导入登录态，或配合pdd_HAR_reader.py、jingxi_HAR_reader.py解析本地抓包文件（.har）提取关键接口数据。taobaoSpider.py、jdSpider.py、marketSpider.py分别对应平台主逻辑，functions目录封装了页面等待、元素点击、滚动加载、异常重试等通用动作，error.wav用于运行出错时本地语音提醒。requirements.txt明确列出依赖版本，适配主流Python环境；docs和get_har.md提供Har包获取指引与调试说明；LICENSE和CODE_OF_CONDUCT.md确保使用合规。适合做竞品店铺横向对比、行业类目分布统计、新店成长跟踪、选品前期摸底等轻量级电商数据采集任务。
1. 项目概述：为什么这套工具能真正“开箱即用”，而不是又一个半途而废的爬虫脚本？
你有没有试过在淘宝搜一家店铺，点进主页，想快速记下“这家店开了几年？卖什么最火？评分稳不稳？”——结果发现页面信息藏得深：开店时间在“店铺档案”二级页里，粉丝数要等懒加载滚动到底才出现，DSR评分还分描述、服务、物流三项，且每项都带动态动画延迟渲染。更别提京东的“店铺介绍”和拼多多的“商家资质”入口位置完全不同，结构毫无规律可言。这时候，复制粘贴就不是效率问题，而是根本不可行。我做过三年电商数据支持，每天要盯20+竞品店，早期靠人工截图+Excel手动录入，平均一店耗时7分钟，出错率超15%。后来试过Requests+正则硬解析，结果淘宝首页HTML被压缩成一行、京东商品数藏在JSONP回调里、拼多多干脆返回空div——全军覆没。直到我把思路彻底倒过来：不跟HTML斗智斗勇，直接让程序像人一样点、滚、等、读。这就是这套工具的核心逻辑——它不追求“最快”，而追求“最稳”。Selenium不是万能钥匙，但它是目前唯一能跨平台、跨结构、跨渲染机制稳定落地的方案。关键词里写的“淘宝京东拼多多店铺采集”“Selenium爬虫”，不是技术堆砌，而是对现实场景的精准回应：三大平台反爬策略差异极大（淘宝重行为检测、京东重Referer与User-Agent组合校验、拼多多重Har包签名时效），单一技术栈必然失效；而“一键采集”也不是营销话术，它体现在三个真实细节上：第一，GetCookie.py让你用浏览器手动登录后导出Cookie，绕过所有滑块/短信验证，把“登录”这个最不稳定环节交给真人；第二，pdd_HAR_reader.py和jingxi_HAR_reader.py直接解析你用浏览器开发者工具录下的.har文件，把拼多多和京东的API请求从网络层直接捞出来，完全不触发前端JS渲染逻辑；第三，error.wav语音提醒不是炫技，是当你在后台跑着10个店铺采集任务时，突然某一个卡死在淘宝“查看全部评价”弹窗上，你不用切屏看日志，声音一响就知道哪台机器出问题了。它适合谁？不是要建数据中台的团队，而是运营专员做周度竞品快照、选品经理扫类目新店、小商家主理人摸清对手底细——这些人不需要懂XPath，只需要知道“双击run.bat，等三分钟，看output.csv”。我把它部署在公司内网树莓派上，每周日凌晨自动跑一次TOP100女装店，三年没修过一行核心代码。因为它的设计哲学很朴素：把人必须做的动作，拆解成原子化步骤；把机器容易崩的环节，交给最可靠的载体（人手、Har包、语音）。
2. 整体架构与模块协同逻辑：为什么模块化不是为了炫技，而是生存必需
这套工具的目录结构看似普通，但每个文件名背后都是踩坑后长出来的骨头。我们先看最常被忽略的“functions”目录——它不是工具函数集合，而是整个系统的神经反射弧。比如functions/wait_for_element.py里的wait_for_visible()函数，表面只是等元素出现，实际封装了三层防御：第一层用WebDriverWait配合presence_of_element_located判断DOM是否存在；第二层叠加visibility_of_element_located确认元素未被CSS隐藏；第三层加了个force_check参数，当检测到元素存在但尺寸为0（常见于拼多多“加载中…”占位符），会主动执行js滚动到视口并触发resize事件。这种设计源于一次真实故障：京东某店铺的“主营类目”文字被包裹在div里，但div初始height=0，等动画结束后才展开，纯等待visibility会永远超时。再看taobaoSpider.py和jdSpider.py的差异：淘宝脚本里大量使用execute_script(“window.scrollTo(0, document.body.scrollHeight)”)模拟滚动，因为其粉丝数、商品数等数据依赖懒加载；而京东脚本几乎不用滚动，转而用find_element(By.XPATH, “//div[@class=’seller-info’]//span[contains(text(),’成立时间’)]/following-sibling::span”)直取静态文本——因为京东店铺页源码里已包含基础信息，滚动反而触发风控。这种平台级策略差异，正是通过functions目录的通用能力（如scroll_to_element(), click_with_retry()）实现复用，避免每个脚本重复造轮子。重点说说Har包解析模块的不可替代性。拼多多的店铺数据90%以上来自一个叫“/api/mall/shop/info”的接口，但该接口要求Header里带x-sign签名，且签名算法随版本更新频繁变动。pdd_HAR_reader.py不碰算法，它只做一件事：打开你手动录制的.har文件，用json.load()解析，遍历entries列表，用正则匹配url包含”mall/shop/info”的entry，再从entry[“response”][“content”][“text”]里提取原始JSON字符串。这招看似笨拙，实则是唯一可持续方案——签名算法变，你只要重新录一次.har；接口路径变，改一行正则就行。对比之下，taobaoSpider.py走的是纯Selenium路线，因为它需要处理淘宝特有的“旺旺在线状态”动态图标、DSR评分星星动画等视觉反馈，这些无法从Har包获取。而marketSpider.py作为聚合调度器，它的核心价值不在代码量，而在错误熔断机制：当taobaoSpider.py连续3次超时，它不会继续重试，而是自动降级调用GetCookie.py检查当前Cookie是否过期，并触发邮件告警。这种模块分工，本质是把“稳定性”拆解成可独立维护的单元：functions管动作可靠性，平台脚本管页面逻辑适配，Har模块管接口数据兜底，调度器管全局容错。你可能会问：为什么不用Scrapy+Splash？答案很现实——Splash容器启动慢、内存占用高，跑10个店铺要开10个浏览器实例，而Selenium Grid配置复杂，中小企业根本养不起运维。这套方案用单机ChromeDriver，靠模块隔离实现“一个平台崩，不影响其他”，这才是轻量级场景的真实需求。
3. 核心采集逻辑与实操要点：从“看到数据”到“稳定拿到数据”的关键跨越
3.1 淘宝店铺采集：如何应对“动态渲染+懒加载+行为检测”的三重门
淘宝的反爬不是靠封IP，而是靠识别“非人行为”。我实测过，如果脚本一打开页面就疯狂点击“查看全部评价”，大概率触发风控弹窗。taobaoSpider.py的破解逻辑是：用时间换安全，用节奏换稳定。第一步，启动Chrome时注入–disable-blink-features=AutomationControlled参数，并用execute_cdp_cmd()移除webdriver属性，这步能骗过80%的初级检测。第二步，绝不跳过“人类等待”：访问店铺首页后，强制sleep(3)秒，再执行scroll_to_element()滚动到“宝贝分类”区域，停顿2秒；接着滚动到“店铺动态评分”区域，停顿1.5秒。这个节奏模仿了真人浏览习惯——没人会一进店就直奔评分。第三步，DSR评分的获取是最大难点。淘宝把三项评分（描述相符、服务态度、物流服务）渲染成SVG星星图，DOM里只有
3.2 京东店铺采集：为什么“静态文本优先”比“动态渲染”更高效
京东的店铺页是三大平台中最“老实”的——基础信息基本都在首屏HTML里。jdSpider.py的策略因此截然不同：放弃一切滚动和等待，直取源码。但它有个致命陷阱：京东会根据User-Agent返回不同HTML结构。测试发现，用Chrome默认UA访问，商品数字段在
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
