简介：面向淘宝开放平台以及淘宝、天猫、阿里巴巴等电商站点的登录与数据抓取场景，这套爬虫软件开发工具包提供了登录模拟、验证码与Cookie处理、商品详情/价格/评论采集等核心模块，适合需要做市场分析、竞品监控、价格追踪或数据挖掘的开发者。工具包源码经过严格测试，压缩包内既有可直接运行的Python脚本，也带wheel安装包和依赖清单，主程序、API接口示例、说明文档及许可证一应俱全，可帮助使用者减少重复调试，快速搭建合规的数据采集流程。资源共17个文件，以Python源码为主，辅以配置文件、JSON数据、清单和文档，整体压缩后仅54KB，轻量易用，目录结构清晰。内容预览显示其中TSDK-master目录涵盖主程序、API封装与示例代码，便于直接阅读或二次开发。目前已有144人学习下载，适合具备一定Python基础、希望高效获取电商开放平台数据的开发者。
1. 淘宝爬虫SDK：它到底是开放平台API的封装，还是登录爬取的脚手架？
做淘宝、天猫、阿里巴巴数据采集的工程师，迟早会在某个压缩包里见到“淘宝爬虫SDK”这类名字。它的目标其实很直白：把开放平台的授权调用和页面端的登录爬取收拢成一套统一接口，让爬虫从“怎么登录、怎么签名、怎么防封”的脏活里腾出手来。下面就从工程落地的角度拆解这套东西：SDK的分层怎么设计、登录会话怎么管、请求签名怎么写、数据怎么用SQLAlchemy落库，以及哪些场景最容易翻车。适合手里有一定Python基础、正准备接入淘宝系数据采集的开发者，读完可以自己拼出一个能复现的SDK骨架，而不是拿到压缩包只会解压。
2. 拆解两种数据来源：开放平台API与登录爬取，SDK为什么不偏科
2.1 开放平台API的边界：能拿到什么、拿不到什么
淘宝开放平台是一套正规的API体系，申请应用后可以调用商品、订单、物流等接口。它的优点是文档齐全、有官方配额，但实际操作下来会发现边界很明显：开通权限要提交材料，审核周期以天计；很多核心字段并不在开放接口里，比如商品详情页里的实时到手价、店铺直播间的当前状态；订单接口往往只能查到最近三个月的数据；调用要带app_key和签名，签名规则一变，老代码立刻作废。
有些人觉得，既然开放平台API正规，那登录爬取就没必要了。实际上，开放平台很多接口只返回汇总数据，比如订单报表，你想看每个SKU的退款标签、买家留言，API里根本没有字段。反过来，只做登录爬取又容易在权限上反复折腾。两套一起做，用开放平台API做数据底座，用登录爬取做定向补充，是目前淘宝、天猫、阿里巴巴数据采集里比较可靠的组合。阿里巴巴的开放平台接口签名风格与淘宝接近，但字段命名更国际化，切换时不能直接套同一个解析器。
2.2 登录爬取要补哪些能力：从Cookie到会话保持
登录爬取比开放平台API麻烦得多。它要模拟真实的浏览器登录流程：要么扫码，要么账号密码加滑块；登录成功后拿到的是Cookie或Token，而且这些凭证会过期、会被风控点名。爬取端要做的，是在每次请求里带上这些凭证，保持同一个会话上下文，遇到302跳转登录页时能第一时间发现凭证失效。
这套SDK要补的能力，大致有四块：一是本地会话持久化，把登录凭证存到文件或表里，重启脚本不用重新扫码；二是请求签名，页面接口有些也要算签名参数，把参数按字典序排列再拼接加密是常见做法；三是频率控制，把请求间隔控制在合理范围；四是失败重试，遇到网络抖动或临时限流能自动退避。这四块是登录爬取SDK的骨架，后面章节会逐一展开。
2.3 SDK分层设计：一个能跑的骨架长什么样
我一般会把SDK分成三层。网络层负责requests.Session的创建、超时、重试；业务层负责登录、订单列表、商品详情这些具体动作；数据层负责把抓到的结果映射成SQLAlchemy模型。这样设计的好处是，登录爬取和开放平台API可以共用网络层与数据层，只在业务层做不同实现。
taobao_sdk/ ├── core/ │ ├── network.py # Session 管理、重试、超时 │ ├── sign.py # 请求签名工具 │ └── rate_limit.py # 频率控制 ├── auth/ │ ├── login.py # 扫码登录/账号密码登录 │ └── session_store.py # Cookie 持久化 ├── business/ │ ├── order.py # 订单接口封装 │ ├── item.py # 商品详情封装 │ └── api.py # 开放平台 API 封装 ├── storage/ │ ├── models.py # SQLAlchemy 模型 │ └── writer.py # 落库、去重逻辑 ├── config.py └── main.py目录结构不是拍脑袋想的：core层不依赖具体业务，换接口只需要在business层加一个模块；auth层独立出来，因为登录逻辑是这两个数据源最容易踩坑的地方；storage层单独放，方便你后面把数据从SQLite迁到MySQL。代码里我刻意把session相关的东西放在auth层而不是core层，原因是开放平台API用的是app_key/app_secret签名，页面爬取用的是Cookie，两者凭证不同，混在一起容易出鬼。
签名是实现里最容易抄错的一环。常见的签名逻辑是：把业务参数按key做字典序排序，拼接成k1=v1&k2=v2的字符串，再拼上app_secret做摘要。注意，页面接口的签名参数名可能是sign，开放平台可能是sign_method，别搞混。
# core/sign.py 最小签名实现 import hashlib from urllib.parse import urlencode def sign_params(params: dict, secret: str) -> str: # 去掉为空的参数，避免签名结果不稳定 filtered = {k: v for k, v in params.items() if v not in (None, "")} # 按 key 排序后拼接，顺序错误会直接签名失败 raw = "&".join(f"{k}={filtered[k]}" for k in sorted(filtered.keys())) return hashlib.md5((raw + secret).encode("utf-8")).hexdigest()这里sorted排序是关键，参数顺序一乱，服务端验签必挂。secret拼接方式以目标接口的文档为准，有的放在字符串末尾，有的放在开头，换接口时先拿一个已知参数集做联调，别一上来就跑全量爬取。
另一个容易忽略的点是网络层要把“请求重试”和“业务重试”分开。网络重试解决的是连接被重置、超时这类基础问题；业务重试解决的是接口返回了错误码、需要重新登录这类上层问题。混在一起的结果，往往是Cookie失效后脚本会带着死Cookie反复重试同一个接口，白白消耗请求次数。所以我在network.py里只做2次TCP级别的重试，业务层再根据响应码决定是重试还是重新登录，这个边界不能省。
| 维度 | 开放平台API | 登录爬取 |
|---|---|---|
| 凭证 | app_key/app_secret | Cookie/Token |
| 数据范围 | 受限的开放字段 | 页面可见字段几乎都能拿 |
| 权限获取 | 需要申请应用权限 | 不需要申请，但要防风控 |
| 频控政策 | 官方配额 | 自己控频，受限流影响 |
3. 把登录爬取跑通：从握手到拿数据的最短路径
3.1 初始化SDK：加载配置与本地会话
一切从初始化开始。SDK需要读一份配置，里面放着app_key、app_secret、目标店铺ID或类目ID，以及一个本地会话文件的路径。会话持久化是登录爬取SDK和普通脚本最大的区别：扫码登录一次，后面三天内重启脚本都不需要再扫。
# config.py 简单配置加载 import json import os DEFAULT_CONFIG = { "app_key": "", "app_secret": "", "session_file": "session.json", "request_timeout": 10, "retry_times": 2, "rate_delay": (1, 3) # 每次请求间隔的秒数范围 } def load_config(path="config.json"): if not os.path.exists(path): return DEFAULT_CONFIG with open(path, "r", encoding="utf-8") as f: cfg = {**DEFAULT_CONFIG, **json.load(f)} return cfg配置加载用字典合并而不是直接覆盖，是为了让默认值兜底。rate_delay用一个范围而不是固定数字，是为了让请求间隔带随机抖动。timeout设10秒在爬淘宝这种大流量站点时比较合理，太短容易误判超时，太长会拖慢抓取。
3.2 登录流程：二维码登录与账号密码的取舍
登录是登录爬取SDK里最玄学的一环。账号密码登录要处理滑块、短信验证码，而且很容易触发二次验证；二维码登录反而更省事，因为扫码动作是人做的，风控模型对它的判断宽松很多。所以我一般默认实现二维码登录：后端接口返回二维码内容，前端或脚本把它渲染出来，然后轮询扫码结果。
# auth/login.py 二维码登录轮询逻辑 import time import requests def login_by_qrcode(session, poll_url, qr_payload, timeout=120): # 拿到二维码内容，打印成 ASCII 码或交给前端渲染 qr_content = qr_payload.get("content") print(f"请扫码登录，二维码内容长度 {len(qr_content)}") start = time.time() while time.time() - start < timeout: # 轮询间隔要和服务端约定，通常是 1.5 秒到 2 秒 resp = session.post(poll_url, json={"qr_id": qr_payload["id"]}) data = resp.json() if data.get("status") == "confirmed": # 确认后服务端会下发正式 Cookie，塞进 session session.cookies.update(data["cookies"]) return True if data.get("status") == "expired": return False time.sleep(1.5) return False轮询间隔别改得太快。1.5秒一次是经验值，改到0.5秒并不会显著加快登录速度，反而容易让服务端认为在刷接口。返回后立刻把cookies做持久化，别等抓完数据再存，因为登录态会过期。
3.3 抓取订单：翻页与请求签名
订单列表是登录爬取最常见的业务。页面接口一般按页返回，每页20到50条，SDK要做的就是把页码、时间范围、排序方式这些参数组织好，加上签名，然后循环拉取直到没有下一页。
# business/order.py 订单列表抓取 from core.sign import sign_params def fetch_orders(session, base_url, biz_params, app_secret, max_pages=100): all_orders = [] for page in range(1, max_pages + 1): params = { "page": page, "page_size": 50, "start_time": biz_params["start_time"], "end_time": biz_params["end_time"], # 常见做法是放一个时间戳防缓存 "t": int(time.time() * 1000) } # 注意：高频参数要参与签名，明文请求很容易被服务端识破 params["sign"] = sign_params(params, app_secret) resp = session.get(base_url, params=params, timeout=10) data = resp.json() batch = data.get("orders", []) all_orders.extend(batch) # 拿到空列表说明到底了，break 比继续翻页省资源 if not batch or page >= data.get("total_pages", page): break # 翻页间隔用后面的频率控制器，不要在这里裸 sleep time.sleep(2) return all_orderspage_size用50是折中值，太大容易撑爆响应体，太小请求次数翻倍。t参数是很多站点防缓存的标准做法，参与签名是为了避免被直接重放。total_pages字段不是每个接口都有，没有的时候就以“返回条数小于page_size”作为结束信号，这个逻辑要按接口文档改。
3.4 数据落库：用SQLAlchemy把爬虫结果存成结构化表
抓回来的是字典列表，直接塞进数据库会出各种幺蛾子，比如重复插入、字段缺失。用SQLAlchemy定义模型，再加上upsert写库，是python爬虫里比较省心的做法。
# storage/models.py 订单模型与 upsert 写库 from sqlalchemy import create_engine, Column, String, DateTime, BigInteger from sqlalchemy.dialects.sqlite import insert as sqlite_insert from sqlalchemy.orm import declarative_base, sessionmaker Base = declarative_base() class Order(Base): __tablename__ = "orders" # 订单号天然唯一，直接拿来做主键 trade_id = Column(String(32), primary_key=True) title = Column(String(256), nullable=False) pay_amount = Column(BigInteger, default=0) status = Column(String(16), index=True) created_at = Column(DateTime) def upsert_orders(engine, orders): Session = sessionmaker(bind=engine) stmt = sqlite_insert(Order).values(orders) # SQLite 的 upsert 在冲突时更新两个核心字段就行 stmt = stmt.on_conflict_do_update( index_elements=[Order.trade_id], set_={"status": stmt.excluded.status, "pay_amount": stmt.excluded.pay_amount} ) with Session() as s: s.execute(stmt) s.commit()Order模型里pay_amount用整数分而不是浮点元，是对金额类数据的保守做法，避免浮点误差。upsert的关键是主键要稳定，trade_id这个字段从淘宝系接口里拿，不会变。如果你要迁移到MySQL，把sqlite_insert换成mysql方言的insert，冲突处理语法略有不同，但思路一样。
把上面几块拼起来，最小可跑的命令大概是：
# main.py from core.network import build_session from auth.login import login_by_qrcode from business.order import fetch_orders from storage.models import upsert_orders, engine if __name__ == "__main__": cfg = load_config() session = build_session(cfg) if not login_by_qrcode(session, cfg["poll_url"], cfg["qr_payload"]): raise SystemExit("登录超时") orders = fetch_orders(session, cfg["order_url"], cfg, app_secret=cfg["app_secret"]) upsert_orders(engine, orders) print(f"入库订单 {len(orders)} 条")这段调用链就是整套SDK的骨架：初始化会话、登录、抓取、落库。先保证这条链路能跑通，再去加频率控制和重试，不然前置条件太多，出了问题分不清是登录的锅还是重试的锅。
4. 参数与配置：让SDK在真实环境里顺手复用
4.1 频率控制：sleep与随机延时的把戏
爬虫自用和接单，最大的区别就在控制节奏。写死time.sleep(2)的问题在于，所有请求间隔一模一样，机器行为特征太明显。常见的做法是把间隔做成一个随机范围，中间偶尔插入一个较长的停顿，模拟人工翻页的节奏。
# core/rate_limit.py 带抖动的间隔控制 import random import time def rate_sleep(low=1.0, high=3.0, long_tail_prob=0.05): # 5% 概率来一次长停顿，打断固定的请求节奏 if random.random() < long_tail_prob: time.sleep(random.uniform(8, 15)) else: time.sleep(random.uniform(low, high))low和high要根据接口的承载能力调。新手容易把间隔设得很小，比如0.2秒，爬了一百页没事，五百页后被风控点名。我一般把low设在1以上，连续抓订单时用(1.2, 2.8)，抓商品详情这种高频接口时用(2, 4)。long_tail_prob不建议超过0.1，太频繁的长停顿会让抓取效率明显下降。
4.2 失败重试与断点续爬
网络抖动和偶发限流是常态，重试要带指数退避，也就是第一次失败等1秒、第二次等2秒、第三次等4秒，而不是每次都立刻重试。同时要有一个游标记录上次抓到哪里，方便断点续爬。
# core/network.py 带退避的请求重试 import time import requests def get_with_retry(session, url, params=None, retries=3, timeout=10): for i in range(retries): try: resp = session.get(url, params=params, timeout=timeout) if resp.status_code == 200: return resp if resp.status_code in (403, 406): # 被拦截了，重试也没用，直接抛给上层重新登录 raise PermissionError("请求被拦截，Cookie 可能失效") except (requests.ConnectionError, requests.Timeout): time.sleep(2 ** i) # 1, 2, 4 秒指数退避 raise RuntimeError(f"请求失败: {url}")403和406不重试，这是血泪经验。被拦截后重试只会加深风控印象，正确做法是停下来检查Cookie，必要时重新登录。只有连接错误和超时才值得重试，这两类错误退避后往往能自愈。
断点续爬的游标通常存一个JSON文件或一张表，记录最后成功的页码和时间点。下次启动时从游标继续，而不是从头开始翻几百页，既省时间又不惹人注意。
4.3 Cookie/Token的存取与失效检测
Cookie是登录爬取SDK的黑匣子。它什么时候失效，你只能通过接口响应去猜。常规做法是登录成功后把Cookie序列化到本地，每次请求前检查过期时间；但服务端的风控可能随时让Cookie提前失效，所以还要在响应里做主动探测。
# auth/session_store.py Cookie 持久化与失效探测 def save_cookies(session, path="session.json"): with open(path, "w", encoding="utf-8") as f: json.dump(session.cookies.get_dict(), f) def load_cookies(session, path="session.json"): try: with open(path, "r", encoding="utf-8") as f: cookies = json.load(f) session.cookies.update(cookies) return True except (FileNotFoundError, json.JSONDecodeError): return False def probe_session(session, probe_url="https://www.taobao.com/"): resp = session.get(probe_url, timeout=10, allow_redirects=False) # 跳到登录页的典型标志：302 或响应里出现 login.taobao.com if resp.status_code in (301, 302) and "login" in resp.headers.get("Location", ""): return False return Trueprobe_session是一个花钱也买不到的后悔药接口。每次大规模抓取前先探测一次会话，能帮你避开“抓了两百页才发现Cookie早就失效”的大坑。save_cookies建议在登录成功后立刻调用，不要等脚本结束时再存，因为脚本可能中途崩掉。
很多爬虫脚本会把requests.get写成独立请求，每次都新建连接，这在低频抓取时没问题，但高频抓取会频繁重建TCP连接，增加被识别为机器的概率。SDK里全程用同一个requests.Session，是为了复用连接池和Cookie。时区参数也要注意：淘宝系接口的时间参数一般不带时区，直接用本地时间拼接容易导致查不到数据，我也会在配置里固定成Asia/Shanghai，避免在服务器上因为时区不同而出现“数据对不上”的幻觉。
5. 避坑手册：淘宝登录爬取常见的5个翻车现场
5.1 现象：扫码登录成功，但脚本一跑请求就302
原因：登录时用的Session和抓取时用的Session不是同一个实例，Cookie没带过去；或者UA在两次请求里不一致，服务端判定为可疑会话。解决：全局只保留一个Session，登录和抓取共用它；UA固定成同一串字符串，不要每次请求动态生成。
5.2 现象：接口返回200，但data字段是空的
原因：页面接口换了参数名，或者多了一个必填的签名参数；还有可能是返回里套了一层JSONP包装，直接.json()解析失败。解决：先用浏览器开发者工具手动发一次同样的请求，把响应文本原样打出来看前200个字符，确认是新格式再改代码。不要盲目改签名。
5.3 现象：滑块验证码频繁弹出，过不去
原因：请求频率太高或者参数里的t时间戳明显异常；无头浏览器模式容易被识别。解决：把间隔拉到3秒以上，时间戳用当前时间戳，不要固定写死；有头模式配合随机移动轨迹，比无头模式通过率高很多。滑块逻辑能不做就不做，优先走二维码登录。
5.4 现象：数据库订单越插越多，同一单出现两条
原因：没有给trade_id建唯一约束，upsert没生效；或者同一个订单在两个时间范围内被重复爬到。解决：给trade_id加主键或唯一索引；抓取时把时间范围做成左闭右开[start, end)或记录上次时间游标，避免边界重复。
5.5 现象：请求频率不高，却频繁超时
原因：当前机器的外网IP被临时限流，或者目标接口在某个时段做了熔断；也可能是本地连接池没关闭，连接数占满。解决：把并发数降下来，确认用的是Session而不是每次新建连接；记录超时发生时的时间点，看是不是固定整点触发，如果是，就把抓取窗口避开那个时段。
6. 进阶：从登录爬取走向开放平台API的合规过渡
6.1 同一个SDK里封装两种数据源
当登录爬取跑顺之后，下一步往往是接开放平台API来替换部分高风险页面接口。做法是在business层加一个api.py，里面用app_key/app_secret实现开放平台风格的调用，返回的数据结构和页面爬取的统一转成相同的Order字典，这样storage层完全不用改。
# business/api.py 开放平台 API 封装示意 def fetch_orders_via_api(app_key, app_secret, start_time, end_time): params = {...} # 开放平台要求的业务参数 params["app_key"] = app_key params["sign"] = sign_params(params, app_secret) resp = requests.post(API_ENDPOINT, data=params) # 注意开放平台大多是 POST return normalize(resp.json()) # 转成和页面爬取一致的 schema开放平台接口大多是POST而不是GET，签名要放在body里，这个和页面接口差别很大。normalize是过渡期的关键，它把两个数据源的字段名、金额单位、时间格式统一成一份，后面核对数据时才不会对不上。
6.2 验证：订单数据一致性核对
从登录爬取切到开放平台API时，不要直接替换，先双跑几天。核对逻辑很简单：以trade_id为准，对比两个源的订单数、金额总和、状态分布。
# verify.py 双数据源核对 def verify_sources(page_orders, api_orders): page_ids = {o["trade_id"] for o in page_orders} api_ids = {o["trade_id"] for o in api_orders} only_page = page_ids - api_ids only_api = api_ids - page_ids return { "page-only": len(only_page), "api-only": len(only_api), "overlap": len(page_ids & api_ids) }只要overlap占比在95%以上，同时only_page和only_api都在个位数，就可以切流量。only_api长期为0但only_page有值，说明开放平台API字段覆盖不全，这时候结合业务判断是保留登录爬取还是调整API权限范围。
6.3 把SDK改造成内部服务
跑通之后，把SDK包成一个独立服务，对外提供HTTP接口或命令行，比脏脚本更可控。我习惯把配置、日志、会话文件都放到指定目录，用systemd或cron定时触发，抓取结果直接写库，异常时发一条告警消息。
把登录爬取和开放平台API放在同一个SDK里管理，是我这两年做淘宝系数据采集最实用的决定。登录爬取负责补数据，开放平台API负责做合规兜底，双跑验证之后再逐步缩小爬取范围，整个过程可回退、可追溯。这里面的水很深，签名算法、风控策略、Cookie存活时间，每一项都值得单独写一篇。希望这篇文章能帮你避开我已经趟过的坑，至少让这套SDK从“能跑”变成“敢跑”。希望帮到你。
本文还有配套的精品资源，点击获取
