2026/9/1 19:38:30
FEATURED · 精选文章 
简介这是一套面向电商从业者与Python数据采集初学者的实战工具包聚焦淘宝平台自动化登录与商品数据采集场景解决价格监控、竞品分析等核心业务中的实时数据获取难题。资源压缩包共6个文件88KB包含核心爬虫脚本taobao.py、配置说明README.md与说明文件.txt、使用指南附赠资源.docx、示例数据data.csv及cookie存储文件覆盖从环境配置、登录验证、HTML解析requestsre、时间延时控制到结构化数据输出的完整链路。已有61人学习下载适合希望掌握反反爬基础策略如模拟登录、请求节流、理解电商页面数据提取逻辑的学习者。读者可直接运行调试复现账号自动登录流程提取商品名称、价格、销量、评价等关键字段并基于CSV开展后续分析代码模块清晰、注释完备具备良好可扩展性与二次开发基础。 我最早接触淘宝数据采集是因为一个选品需求要盯着几十个竞品链接的价格变动每天固定时间跑一遍月底拉出比价报表。一开始我图省事直接拿requests.get()抓商品详情页跑了两天就发现问题——部分核心价格数据在匿名状态下根本拿不全而且访问频率稍微上来响应里就开始出现验证页跳转。后来把整套流程改成“登录态持久化 请求伪装 正则提取 延时控制”采集才算真正稳定下来。这篇文章就把这套淘宝商品数据采集系统的设计思路和关键代码拆开讲清楚适合正在做电商价格监控、竞品分析或者想搞明白requests、re、time这三个库怎么配合实战的朋友参考。1. 为什么执着于“模拟登录”价格监控里的隐形门槛1.1 匿名请求到底缺了什么很多人最初的想法和我一样商品详情页是公开的不登录也能看直接抓 HTML 不就行了实际上淘宝的商品详情页在匿名状态下确实能拿到一部分数据比如商品标题、主图、基础售价但真正对价格监控有用的信息往往藏在登录态之后。举几个例子促销价很多时候匿名请求返回的是“吊牌价”或“划线价”而实际成交价、促销价需要登录才能返回完整字段。价格监控如果拿不到真实成交价那报表基本没有参考价值。销量与库存部分 SKU 的销量、库存信息是异步接口加载的并且接口要求带登录态 Cookie否则直接返回空数据或错误码。库存变化本身就是竞品分析的重要信号。优惠券信息商品下方可领取的优惠券、满减活动多数时候依赖登录后的个性化接口。竞品到底叠加了多少优惠力度不登录根本看不到。换句话说匿名抓取不是完全不能用但它拿到的数据是残缺的。用来做“有没有这个商品”这种粗粒度判断还行可一旦要盯价格、算促销周期就必须把登录态问题解决掉。1.2 模拟登录的正确理解需要先说明一点很多人一听到“模拟登录”第一反应是让脚本自动识别验证码、模拟滑块轨迹甚至打码平台对接。这类操作我完全没有可以分享的内容也不建议去研究。原因很简单——验证码和滑块本身就是网站用来区分人类和自动化程序的机制花大力气去模拟它既不稳定又越过了合规边界。实际项目中真正稳妥的“模拟登录”思路是登录一次长期复用登录态。具体来说把浏览器里手动登录后产生的 Cookie 保存到本地文件采集脚本启动时读入 Cookie并让requests.Session自动携带。这样脚本不需要每次都执行登录流程服务器看到的是一个带合法身份的请求。这套方案实现简单、稳定性高也符合“自己的账号、自己的数据、自己负责”的边界。1.3 这个系统到底解决了什么问题整套系统围绕一个核心目标低成本、稳定地把指定商品的价格和相关字段持续采集下来并落到本地供分析使用。它解决的具体问题可以拆成四个问题方案匿名请求拿不到完整价格数据登录态 Cookie 持久化采集时自动携带请求头缺失导致请求被识别补全浏览器特征请求头商品 HTML 结构复杂字段提取困难用正则精准提取标题、价格、店铺名高频访问触发限流time 模块控制请求节奏与随机延时听起来不复杂但每个环节都有不少细节。下面按模块逐步展开。2. 登录态的本质Cookie 与 Session 的存取逻辑2.1 服务器怎么认出“你”用一张会员卡来类比Cookie 就是客户端随身携带的会员卡服务器看到这张卡就知道“哦是熟客”而 Session 是服务器内部保存的对应会员档案。淘宝的登录逻辑同样如此——你登录成功之后浏览器会保存一组 Cookie后续每次请求都会自动带上它服务器靠这组 Cookie 识别你的身份。requests库里对应有两个关键对象requests.Session()会话对象能在多次请求之间自动保存和携带 Cookie还能复用底层 TCP 连接性能比每次新建连接好。Cookie 注入把浏览器里的 Cookie 转成字典通过session.cookies.update()注入之后该会话发起的所有请求都会自动带上。2.2 从浏览器拿 Cookie这一步只需要做一次操作路径如下用 Chrome 打开并登录淘宝。按F12打开开发者工具切到Network网络标签。刷新页面随便点开一个商品详情请求。在Request Headers里找到Cookie字段整段复制出来。拿到 Cookie 字符串之后不要硬编码在代码里。更好用的做法是单独存成一个配置文件比如cookies.json启动时读取。原因是 Cookie 会过期过期时你只需要更新配置文件不用改代码。import json import requests # 假设 cookies.json 内容为 {cookie: tb_tokenxxx; ...} with open(cookies.json, r, encodingutf-8) as f: cookie_str json.load(f)[cookie] # 把 Cookie 字符串解析成字典 cookie_dict {} for item in cookie_str.split(;): item item.strip() if in item: key, value item.split(, 1) cookie_dict[key] value session requests.Session() session.cookies.update(cookie_dict)这段代码每次请求都会带上你手动登录后的身份标识。第一次跑通之后你会发现“登录”这个环节其实只占整个流程的一小部分核心工作反而花在请求头的伪装和页面数据的提取上。2.3 自动登录验证的正规姿势标题里提到的“淘宝账号自动登录验证”我现在的理解更倾向于把它落地成“自动携带登录态验证”而不是“自动破解登录验证码”。这两者有本质区别。正规的做法是首次登录手动在浏览器登录一次把 Cookie 保存到本地。后续运行脚本启动时读取 Cookie 文件注入 Session。失效检测每次请求后检查返回内容里是否出现“请登录”“滑动验证”等关键词一旦出现就停止采集并提示人工处理。import re import requests session requests.Session() # 注入 Cookie 的代码略同上一节 login_check_keywords [请登录, 滑动验证, 亲请登录] resp session.get(https://item.taobao.com/item.htm?id商品ID, headersheaders, timeout10) if any(keyword in resp.text for keyword in login_check_keywords): print(登录态已失效请重新手动登录并更新 cookies.json) exit(1)这里要特别强调一点如果触发了验证码或滑块正确的处理方式是停下脚本、人工过一下验证然后把新的 Cookie 再更新到文件里。任何尝试用第三方库去模拟滑块轨迹的行为我都强烈不建议这条路不稳定、不合规而且对方风控升级一次你就得重新适配一次纯属给自己找麻烦。2.4 登录态失效的判断与恢复失效不一定表现为 HTTP 状态码异常很多时候页面状态码依然是 200但响应内容已经变了。所以判断登录态是否还有效要依赖内容层面的特征词。我自己的经验是维护一个小的候选项列表判断时优先看页面里是否出现登录入口相关文案同时配合检查核心数据字段是否存在。比如抓详情页时会固定找window.__INITIAL_DATA__或者商品标题标签如果这些都没了说明页面大概率被重定向到了登录页或验证页。恢复流程也很简单删除失效的cookies.json手动打开浏览器重新登录重新导出 Cookie 更新文件重新运行脚本整个过程两分钟搞定远比调各种自动识别方案划算。3. 请求伪装三板斧Requests 库的核心用法3.1 请求头是关键登录态只是第一步服务器还会通过请求头信息判断客户端是不是正常浏览器。最容易踩的坑是请求头不全。以商品详情页为例最少要包含下面这几个字段字段名作用示例值User-Agent标识浏览器类型和版本Mozilla/5.0 (Windows NT 10.0; Win64; x64)Referer告诉服务器请求来源页面https://www.taobao.com/Accept客户端可接受的内容类型text/html,application/xhtmlxml,...Accept-Language客户端语言偏好zh-CN,zh;q0.9很多人会忽略Referer但实际上不少页面会校验这个字段缺了以后请求返回的数据可能不完整。所以标准做法是构造一个全局请求头字典所有请求共用headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, Referer: https://www.taobao.com/, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }User-Agent一定不要用python-requests默认值那个一眼就能看出来。一般直接从浏览器的Network面板里复制一个当前 Chrome 的 UA 就行。3.2 会话复用与连接优化使用requests.Session()而不是反复调用requests.get()除了自动管理 Cookie还能复用底层 TCP 连接。对于需要批量采集大量商品页的场景连接复用能明显减少握手耗时整体采集时间会缩短不少。session requests.Session() session.headers.update(headers) session.cookies.update(cookie_dict)之后的所有请求都走session.get()不需要再手动传headers和cookies。这个细节看起来不起眼但在跑几百个链接的时候节省的时间非常可观。3.3 响应内容校验请求发出去了不代表数据就一定能用。一个合格采集脚本必须对响应做三层校验状态码校验resp.status_code 200才继续否则记录日志并跳过。编码校验淘宝页面有时候返回的是gbk或gb2312编码直接打印会出现乱码。稳妥的做法是用resp.apparent_encoding来兜底或者从响应头的charset字段判断。内容校验检查关键数据是否存在避免采到验证页、空页或错误页。一个顺手的小工具函数可以这样写def safe_get(session, url, retries3): for i in range(retries): try: resp session.get(url, timeout10) if resp.status_code 200 and item in resp.url: resp.encoding resp.apparent_encoding return resp.text except requests.RequestException as e: print(f请求失败剩余重试次数: {retries - i - 1}, 错误: {e}) time.sleep(1.5) return None超时和重试一定要设计好。淘宝这种大流量站点偶发超时太正常了直接退出脚本反而影响采集连续性。3.4 有些数据在接口里不在 HTML 里这是很多新手会卡住的地方明明页面渲染出来有价格但抓回来的 HTML 源码里怎么找都找不到。原因很简单价格和销量这类数据是通过页面里的 JavaScript 异步请求接口加载的初始 HTML 里只有一个空壳。这种情况下不要再盯着 HTML 硬啃。用开发者工具切到Network面板筛选XHR或Fetch请求找到真正返回价格数据的接口直接在脚本里请求这个接口解析 JSON 反而更简单。接口请求同样要带上登录态和请求头。需要注意部分接口的地址里带有时间戳或签名参数这些参数通常是从页面源码头部的 JS 脚本里生成的处理时要先看一下具体规则按实际场景适配。这部分因页面版本而异没有统一写法需要在抓包后微调。4. 商品信息提取实战正则表达式这样写才够稳4.1 为什么这套系统选 re很多人会问解析 HTML 为什么不用 BeautifulSoup 或 XPath非要用正则这个选择是基于这套系统的实际约束。淘宝的商品详情页源码是 HTML 和 JSON 混排的大量数据嵌在script标签的 JavaScript 变量里。用 BeautifulSoup 去解析这种混合结构需要先定位到script再单独处理反而绕远路。而正则表达式是纯文本匹配直接对着源码找关键字段写法直观性能也好。另外正则表达式的健壮性并不差。只要商品页面模板没有大改字段在源码里的出现位置基本稳定一旦匹配模式写好可以连续用很久。所以标题里指定re作为提取工具在这个场景下是合理选择。4.2 核心字段的提取写法以商品详情页为例我通常提取这几个字段商品标题、价格、店铺名称、销量和商品 ID。商品标题标题一般出现在title标签、meta标签的og:title属性里或者在页面源文件开头的 JSON 数据中。优先用meta标签因为它的格式固定不需要处理标题里可能出现的其他标签噪声。import re def extract_title(html): m re.search(rmeta[^]propertyog:title[^]content([^]), html) if m: return m.group(1) m re.search(rtitle([^])/title, html, re.S) return m.group(1).strip() if m else 价格价格字段的提取要小心页面上往往同时存在多个价格比如原价、促销价、到手价。我之前总结过一个优先级策略先尝试匹配price或成交价附近 JSON 字段中的数值再尝试匹配源码中形如促销价: 12.90或price:12.90的片段最后才考虑从可见文本里按“价格符号数字小数点”模式抓取。一个通用兜底正则def extract_price(html): # 优先匹配 JSON 字段 m re.search(rprice\s*:\s*?(\d\.?\d*)?, html) if m: return float(m.group(1)) # 兜底匹配页面中常见的价格模式 m re.search(r([¥])\s*(\d\.?\d*), html) return float(m.group(2)) if m else None严格来说不同业务场景价格字段完全不一样这个正则到了你自己抓的页面上大概率要微调但思路是通用的先精确找 JSON 片段再放宽范围做兜底。店铺名店铺名一般出现在seller、shopName、nick这类字段附近def extract_shop_name(html): m re.search(rshopName\s*:\s*([^]), html) if m: return m.group(1) m re.search(rnick\s*:\s*([^]), html) return m.group(1) if m else 4.3 贪心与非贪婪以及转义处理正则最经典的坑就是贪婪匹配。比如用rtitle(.*)/title去匹配标题如果页面里title后面还有其他标签.*会尽可能多地匹配导致结果把整个页面后半段都吞进去。解决方法是改成非贪婪模式rtitle(.*?)/title。另外淘宝页面源码里常见 HTML 实体和 Unicode 转义。比如标题里的amp;实际是价格文本里的\u00a5实际是人民币符号。提取完之后需要统一清洗import html as html_mod def clean_text(text): text html_mod.unescape(text) # 去掉多余的空白符和换行 text re.sub(r\s, , text).strip() return text4.4 从原始文本到结构化数据提取字段只是第一步最终要变成结构化数据才能入库和做分析。我一般定义一个字典把字段汇总再统一写入 CSV 或数据库def parse_item(html, item_id): return { item_id: item_id, title: clean_text(extract_title(html)), price: extract_price(html), shop: clean_text(extract_shop_name(html)), crawled_at: time.strftime(%Y-%m-%d %H:%M:%S), }字段名、格式统一之后后面无论是做价格趋势分析还是竞品对比都会省去大量数据清洗的功夫。这一点我吃过亏早期采集时字段名不统一不同批次的数据叠加在一起后面做分析之前先花了一整天整理字段教训深刻。5. 延时与频率控制Time 库是爬虫的保命符5.1 延时不是怂是策略做爬虫的人都绕不开一个现实问题你是在访问别人的服务器。即使你带着登录态如果请求频率高到人类不可能做到服务器就有理由判定为异常流量。这里说的“异常”不只是封号风险还包括最直接的技术信号——429 Too Many Requests。我早期写采集脚本时为了追求速度把延时调到 0.5 秒一次跑了不到半小时响应开始出现大量429再往后直接变成验证页。那次的直接教训是请求越快采集任务死得越快。5.2 time.sleep 的两种正确姿势time.sleep()是 Python 里最直接的延时控制手段但要会用。固定延时time.sleep(3)每两次请求之间固定等 3 秒。写法简单缺点是节奏太规律服务器端很容易通过时间序列识别出自动化程序。随机延时import random import time time.sleep(random.uniform(2, 5))每次等待 2 到 5 秒之间的随机值。这个方式模拟了人类浏览时的不确定性节奏更自然。实测下来随机延时的采集任务比固定延时的任务稳定很多。5.3 429 状态码的应对策略如果已经收到429说明服务端已经明确告诉你“请求太快了”这时候最忌讳的是立刻重试。正确做法是退避冷却休息一段时间再继续。指数退避的思路是第一次失败等 5 秒第二次失败等 10 秒第三次等 20 秒以此类推直到恢复。def connect_with_backoff(session, url, max_retries5): delay 5 for i in range(max_retries): resp session.get(url, timeout10) if resp.status_code ! 429: return resp print(f触发 429等待 {delay} 秒后重试) time.sleep(delay) delay * 2 return None收到429之后一定要冷静不要跟服务器较劲先把频率降下来再慢慢恢复采集。5.4 全流程限速设计除了单次请求的延时整个采集任务最好有一份限速方案。这个方案本身不复杂关键是要提前想清楚单页间隔普通商品详情页建议 2 到 5 秒。单批次数量一个批次最多采集 50 到 100 个商品链接跑完休息 5 到 10 分钟再跑下一批。每日总量根据业务需求控制在几百到几千的级别不要贪多。运行时段尽量避开业务高峰时段比如大促当天不要高频拉取。把这些参数直接配置在脚本里任何一次运行都不会超过预设的限速阈值。另外所有请求操作都打日志包括请求时间、状态码、耗时方便后续排障和调整频率。6. 从采集到分析价格监控与竞品对比的最小落地系统6.1 数据存储方案采集到的数据必须落地否则每次都从页面重新抓既浪费流量又容易触发限流。存储方案根据数据规模二选一。CSV 方案适合小规模数据、几十个商品以内的监控。写起来简单可以直接用 Excel 打开预览。import csv def save_to_csv(rows, filenameitems.csv): fieldnames [item_id, title, price, shop, crawled_at] with open(filename, a, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesfieldnames) if f.tell() 0: writer.writeheader() writer.writerows(rows)SQLite 方案适合长期积累、几百上千个商品、需要做历史价格回溯的场景。SQLite 既能支持 SQL 查询又不需要单独部署数据库服务。import sqlite3 conn sqlite3.connect(price_monitor.db) conn.execute( CREATE TABLE IF NOT EXISTS goods ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_id TEXT, title TEXT, price REAL, shop TEXT, crawled_at TEXT ) ) conn.execute( INSERT INTO goods (item_id, title, price, shop, crawled_at) VALUES (?, ?, ?, ?, ?), (item[item_id], item[title], item[price], item[shop], item[crawled_at]), ) conn.commit()长期跑下来SQLite 文件本身的体积很小但查询效率远高于 CSV尤其是要做“某个商品最近 30 天价格走势”这种查询SQL 一行就能搞定。6.2 价格历史与波动判断数据持续采集之后就能做价格波动分析了。最基础的两个指标是涨跌幅和历史最低价。import sqlite3 conn sqlite3.connect(price_monitor.db) def price_history(item_id, days30): cur conn.execute( SELECT crawled_at, price FROM goods WHERE item_id ? AND crawled_at datetime(now, ?) ORDER BY crawled_at ASC , (item_id, f-{days} days), ) return cur.fetchall()拿到价格序列之后可以计算当前价格相对第一次采集价格的变化幅度当前价格在历史区间内处于什么位置最近一次价格变动发生的时间点这些指标能直接输出成日报供选品或运营决策参考。6.3 竞品分析的几个实用指标价格监控做到位之后自然要往竞品分析方向延伸。基于采集到的结构化数据我常用下面这几个指标指标计算方式用途同款比价按商品标题相似度或 SKU 关联不同店铺的价格找出价格最低的店铺促销频率统计某个商品在一个月内价格变化的次数判断该店铺的调价策略上下架状态如果连续多天采集不到某个商品记录下架时间点判断竞品产品生命周期到手价对比结合优惠券信息计算实际到手价比表面价格更具参考价值比如同款比价最简单的方式是按title做关键词匹配匹配到同一批关键词的商品视为同款再横向对比不同店铺的价格差。这个逻辑不复杂但对选品和定价策略已经很有参考价值。6.4 定时运行与频率建议整套系统跑起来之后把它挂到定时任务里就能持续产生数据。Windows 环境使用“任务计划程序”定时执行 Python 脚本。Linux 环境使用crontab比如每天凌晨 2 点跑一次采集任务。频率怎么设置我的建议是普通价格监控一天 1 到 2 次就够了大促期间可以适当加密到每 3 到 4 小时一次但不要低于 1 小时一次。实际上商品的日常价格波动远没有想象中频繁一天两次基本能覆盖所有关键变化。频率太高只会增加风控风险并不带来额外的信息量。另外每个采集脚本最好加一个运行时长上限比如最多运行 30 分钟就自动退出。这样即使某个环节卡住也不会长时间空转影响定时任务的下一次执行。最后再分享一条我个人的体会这套系统真正难的不是写代码而是数据管理。早期我花了很多精力在请求和解析上结果采集到的数据没有统一的字段规范几个月后想拉价格趋势发现历史数据缺胳膊少腿完全用不上。所以无论你用的是 CSV 还是 SQLite从一开始就要把字段定义清楚、采集时间记录准确。数据质量永远比采集速度重要这也是整个价格监控系统能不能长期发挥作用的关键。本文还有配套的精品资源点击获取
淘宝数据采集实战：登录态、请求伪装与正则提取
简介这是一套面向电商从业者与Python数据采集初学者的实战工具包聚焦淘宝平台自动化登录与商品数据采集场景解决价格监控、竞品分析等核心业务中的实时数据获取难题。资源压缩包共6个文件88KB包含核心爬虫脚本taobao.py、配置说明README.md与说明文件.txt、使用指南附赠资源.docx、示例数据data.csv及cookie存储文件覆盖从环境配置、登录验证、HTML解析requestsre、时间延时控制到结构化数据输出的完整链路。已有61人学习下载适合希望掌握反反爬基础策略如模拟登录、请求节流、理解电商页面数据提取逻辑的学习者。读者可直接运行调试复现账号自动登录流程提取商品名称、价格、销量、评价等关键字段并基于CSV开展后续分析代码模块清晰、注释完备具备良好可扩展性与二次开发基础。 我最早接触淘宝数据采集是因为一个选品需求要盯着几十个竞品链接的价格变动每天固定时间跑一遍月底拉出比价报表。一开始我图省事直接拿requests.get()抓商品详情页跑了两天就发现问题——部分核心价格数据在匿名状态下根本拿不全而且访问频率稍微上来响应里就开始出现验证页跳转。后来把整套流程改成“登录态持久化 请求伪装 正则提取 延时控制”采集才算真正稳定下来。这篇文章就把这套淘宝商品数据采集系统的设计思路和关键代码拆开讲清楚适合正在做电商价格监控、竞品分析或者想搞明白requests、re、time这三个库怎么配合实战的朋友参考。1. 为什么执着于“模拟登录”价格监控里的隐形门槛1.1 匿名请求到底缺了什么很多人最初的想法和我一样商品详情页是公开的不登录也能看直接抓 HTML 不就行了实际上淘宝的商品详情页在匿名状态下确实能拿到一部分数据比如商品标题、主图、基础售价但真正对价格监控有用的信息往往藏在登录态之后。举几个例子促销价很多时候匿名请求返回的是“吊牌价”或“划线价”而实际成交价、促销价需要登录才能返回完整字段。价格监控如果拿不到真实成交价那报表基本没有参考价值。销量与库存部分 SKU 的销量、库存信息是异步接口加载的并且接口要求带登录态 Cookie否则直接返回空数据或错误码。库存变化本身就是竞品分析的重要信号。优惠券信息商品下方可领取的优惠券、满减活动多数时候依赖登录后的个性化接口。竞品到底叠加了多少优惠力度不登录根本看不到。换句话说匿名抓取不是完全不能用但它拿到的数据是残缺的。用来做“有没有这个商品”这种粗粒度判断还行可一旦要盯价格、算促销周期就必须把登录态问题解决掉。1.2 模拟登录的正确理解需要先说明一点很多人一听到“模拟登录”第一反应是让脚本自动识别验证码、模拟滑块轨迹甚至打码平台对接。这类操作我完全没有可以分享的内容也不建议去研究。原因很简单——验证码和滑块本身就是网站用来区分人类和自动化程序的机制花大力气去模拟它既不稳定又越过了合规边界。实际项目中真正稳妥的“模拟登录”思路是登录一次长期复用登录态。具体来说把浏览器里手动登录后产生的 Cookie 保存到本地文件采集脚本启动时读入 Cookie并让requests.Session自动携带。这样脚本不需要每次都执行登录流程服务器看到的是一个带合法身份的请求。这套方案实现简单、稳定性高也符合“自己的账号、自己的数据、自己负责”的边界。1.3 这个系统到底解决了什么问题整套系统围绕一个核心目标低成本、稳定地把指定商品的价格和相关字段持续采集下来并落到本地供分析使用。它解决的具体问题可以拆成四个问题方案匿名请求拿不到完整价格数据登录态 Cookie 持久化采集时自动携带请求头缺失导致请求被识别补全浏览器特征请求头商品 HTML 结构复杂字段提取困难用正则精准提取标题、价格、店铺名高频访问触发限流time 模块控制请求节奏与随机延时听起来不复杂但每个环节都有不少细节。下面按模块逐步展开。2. 登录态的本质Cookie 与 Session 的存取逻辑2.1 服务器怎么认出“你”用一张会员卡来类比Cookie 就是客户端随身携带的会员卡服务器看到这张卡就知道“哦是熟客”而 Session 是服务器内部保存的对应会员档案。淘宝的登录逻辑同样如此——你登录成功之后浏览器会保存一组 Cookie后续每次请求都会自动带上它服务器靠这组 Cookie 识别你的身份。requests库里对应有两个关键对象requests.Session()会话对象能在多次请求之间自动保存和携带 Cookie还能复用底层 TCP 连接性能比每次新建连接好。Cookie 注入把浏览器里的 Cookie 转成字典通过session.cookies.update()注入之后该会话发起的所有请求都会自动带上。2.2 从浏览器拿 Cookie这一步只需要做一次操作路径如下用 Chrome 打开并登录淘宝。按F12打开开发者工具切到Network网络标签。刷新页面随便点开一个商品详情请求。在Request Headers里找到Cookie字段整段复制出来。拿到 Cookie 字符串之后不要硬编码在代码里。更好用的做法是单独存成一个配置文件比如cookies.json启动时读取。原因是 Cookie 会过期过期时你只需要更新配置文件不用改代码。import json import requests # 假设 cookies.json 内容为 {cookie: tb_tokenxxx; ...} with open(cookies.json, r, encodingutf-8) as f: cookie_str json.load(f)[cookie] # 把 Cookie 字符串解析成字典 cookie_dict {} for item in cookie_str.split(;): item item.strip() if in item: key, value item.split(, 1) cookie_dict[key] value session requests.Session() session.cookies.update(cookie_dict)这段代码每次请求都会带上你手动登录后的身份标识。第一次跑通之后你会发现“登录”这个环节其实只占整个流程的一小部分核心工作反而花在请求头的伪装和页面数据的提取上。2.3 自动登录验证的正规姿势标题里提到的“淘宝账号自动登录验证”我现在的理解更倾向于把它落地成“自动携带登录态验证”而不是“自动破解登录验证码”。这两者有本质区别。正规的做法是首次登录手动在浏览器登录一次把 Cookie 保存到本地。后续运行脚本启动时读取 Cookie 文件注入 Session。失效检测每次请求后检查返回内容里是否出现“请登录”“滑动验证”等关键词一旦出现就停止采集并提示人工处理。import re import requests session requests.Session() # 注入 Cookie 的代码略同上一节 login_check_keywords [请登录, 滑动验证, 亲请登录] resp session.get(https://item.taobao.com/item.htm?id商品ID, headersheaders, timeout10) if any(keyword in resp.text for keyword in login_check_keywords): print(登录态已失效请重新手动登录并更新 cookies.json) exit(1)这里要特别强调一点如果触发了验证码或滑块正确的处理方式是停下脚本、人工过一下验证然后把新的 Cookie 再更新到文件里。任何尝试用第三方库去模拟滑块轨迹的行为我都强烈不建议这条路不稳定、不合规而且对方风控升级一次你就得重新适配一次纯属给自己找麻烦。2.4 登录态失效的判断与恢复失效不一定表现为 HTTP 状态码异常很多时候页面状态码依然是 200但响应内容已经变了。所以判断登录态是否还有效要依赖内容层面的特征词。我自己的经验是维护一个小的候选项列表判断时优先看页面里是否出现登录入口相关文案同时配合检查核心数据字段是否存在。比如抓详情页时会固定找window.__INITIAL_DATA__或者商品标题标签如果这些都没了说明页面大概率被重定向到了登录页或验证页。恢复流程也很简单删除失效的cookies.json手动打开浏览器重新登录重新导出 Cookie 更新文件重新运行脚本整个过程两分钟搞定远比调各种自动识别方案划算。3. 请求伪装三板斧Requests 库的核心用法3.1 请求头是关键登录态只是第一步服务器还会通过请求头信息判断客户端是不是正常浏览器。最容易踩的坑是请求头不全。以商品详情页为例最少要包含下面这几个字段字段名作用示例值User-Agent标识浏览器类型和版本Mozilla/5.0 (Windows NT 10.0; Win64; x64)Referer告诉服务器请求来源页面https://www.taobao.com/Accept客户端可接受的内容类型text/html,application/xhtmlxml,...Accept-Language客户端语言偏好zh-CN,zh;q0.9很多人会忽略Referer但实际上不少页面会校验这个字段缺了以后请求返回的数据可能不完整。所以标准做法是构造一个全局请求头字典所有请求共用headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, Referer: https://www.taobao.com/, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }User-Agent一定不要用python-requests默认值那个一眼就能看出来。一般直接从浏览器的Network面板里复制一个当前 Chrome 的 UA 就行。3.2 会话复用与连接优化使用requests.Session()而不是反复调用requests.get()除了自动管理 Cookie还能复用底层 TCP 连接。对于需要批量采集大量商品页的场景连接复用能明显减少握手耗时整体采集时间会缩短不少。session requests.Session() session.headers.update(headers) session.cookies.update(cookie_dict)之后的所有请求都走session.get()不需要再手动传headers和cookies。这个细节看起来不起眼但在跑几百个链接的时候节省的时间非常可观。3.3 响应内容校验请求发出去了不代表数据就一定能用。一个合格采集脚本必须对响应做三层校验状态码校验resp.status_code 200才继续否则记录日志并跳过。编码校验淘宝页面有时候返回的是gbk或gb2312编码直接打印会出现乱码。稳妥的做法是用resp.apparent_encoding来兜底或者从响应头的charset字段判断。内容校验检查关键数据是否存在避免采到验证页、空页或错误页。一个顺手的小工具函数可以这样写def safe_get(session, url, retries3): for i in range(retries): try: resp session.get(url, timeout10) if resp.status_code 200 and item in resp.url: resp.encoding resp.apparent_encoding return resp.text except requests.RequestException as e: print(f请求失败剩余重试次数: {retries - i - 1}, 错误: {e}) time.sleep(1.5) return None超时和重试一定要设计好。淘宝这种大流量站点偶发超时太正常了直接退出脚本反而影响采集连续性。3.4 有些数据在接口里不在 HTML 里这是很多新手会卡住的地方明明页面渲染出来有价格但抓回来的 HTML 源码里怎么找都找不到。原因很简单价格和销量这类数据是通过页面里的 JavaScript 异步请求接口加载的初始 HTML 里只有一个空壳。这种情况下不要再盯着 HTML 硬啃。用开发者工具切到Network面板筛选XHR或Fetch请求找到真正返回价格数据的接口直接在脚本里请求这个接口解析 JSON 反而更简单。接口请求同样要带上登录态和请求头。需要注意部分接口的地址里带有时间戳或签名参数这些参数通常是从页面源码头部的 JS 脚本里生成的处理时要先看一下具体规则按实际场景适配。这部分因页面版本而异没有统一写法需要在抓包后微调。4. 商品信息提取实战正则表达式这样写才够稳4.1 为什么这套系统选 re很多人会问解析 HTML 为什么不用 BeautifulSoup 或 XPath非要用正则这个选择是基于这套系统的实际约束。淘宝的商品详情页源码是 HTML 和 JSON 混排的大量数据嵌在script标签的 JavaScript 变量里。用 BeautifulSoup 去解析这种混合结构需要先定位到script再单独处理反而绕远路。而正则表达式是纯文本匹配直接对着源码找关键字段写法直观性能也好。另外正则表达式的健壮性并不差。只要商品页面模板没有大改字段在源码里的出现位置基本稳定一旦匹配模式写好可以连续用很久。所以标题里指定re作为提取工具在这个场景下是合理选择。4.2 核心字段的提取写法以商品详情页为例我通常提取这几个字段商品标题、价格、店铺名称、销量和商品 ID。商品标题标题一般出现在title标签、meta标签的og:title属性里或者在页面源文件开头的 JSON 数据中。优先用meta标签因为它的格式固定不需要处理标题里可能出现的其他标签噪声。import re def extract_title(html): m re.search(rmeta[^]propertyog:title[^]content([^]), html) if m: return m.group(1) m re.search(rtitle([^])/title, html, re.S) return m.group(1).strip() if m else 价格价格字段的提取要小心页面上往往同时存在多个价格比如原价、促销价、到手价。我之前总结过一个优先级策略先尝试匹配price或成交价附近 JSON 字段中的数值再尝试匹配源码中形如促销价: 12.90或price:12.90的片段最后才考虑从可见文本里按“价格符号数字小数点”模式抓取。一个通用兜底正则def extract_price(html): # 优先匹配 JSON 字段 m re.search(rprice\s*:\s*?(\d\.?\d*)?, html) if m: return float(m.group(1)) # 兜底匹配页面中常见的价格模式 m re.search(r([¥])\s*(\d\.?\d*), html) return float(m.group(2)) if m else None严格来说不同业务场景价格字段完全不一样这个正则到了你自己抓的页面上大概率要微调但思路是通用的先精确找 JSON 片段再放宽范围做兜底。店铺名店铺名一般出现在seller、shopName、nick这类字段附近def extract_shop_name(html): m re.search(rshopName\s*:\s*([^]), html) if m: return m.group(1) m re.search(rnick\s*:\s*([^]), html) return m.group(1) if m else 4.3 贪心与非贪婪以及转义处理正则最经典的坑就是贪婪匹配。比如用rtitle(.*)/title去匹配标题如果页面里title后面还有其他标签.*会尽可能多地匹配导致结果把整个页面后半段都吞进去。解决方法是改成非贪婪模式rtitle(.*?)/title。另外淘宝页面源码里常见 HTML 实体和 Unicode 转义。比如标题里的amp;实际是价格文本里的\u00a5实际是人民币符号。提取完之后需要统一清洗import html as html_mod def clean_text(text): text html_mod.unescape(text) # 去掉多余的空白符和换行 text re.sub(r\s, , text).strip() return text4.4 从原始文本到结构化数据提取字段只是第一步最终要变成结构化数据才能入库和做分析。我一般定义一个字典把字段汇总再统一写入 CSV 或数据库def parse_item(html, item_id): return { item_id: item_id, title: clean_text(extract_title(html)), price: extract_price(html), shop: clean_text(extract_shop_name(html)), crawled_at: time.strftime(%Y-%m-%d %H:%M:%S), }字段名、格式统一之后后面无论是做价格趋势分析还是竞品对比都会省去大量数据清洗的功夫。这一点我吃过亏早期采集时字段名不统一不同批次的数据叠加在一起后面做分析之前先花了一整天整理字段教训深刻。5. 延时与频率控制Time 库是爬虫的保命符5.1 延时不是怂是策略做爬虫的人都绕不开一个现实问题你是在访问别人的服务器。即使你带着登录态如果请求频率高到人类不可能做到服务器就有理由判定为异常流量。这里说的“异常”不只是封号风险还包括最直接的技术信号——429 Too Many Requests。我早期写采集脚本时为了追求速度把延时调到 0.5 秒一次跑了不到半小时响应开始出现大量429再往后直接变成验证页。那次的直接教训是请求越快采集任务死得越快。5.2 time.sleep 的两种正确姿势time.sleep()是 Python 里最直接的延时控制手段但要会用。固定延时time.sleep(3)每两次请求之间固定等 3 秒。写法简单缺点是节奏太规律服务器端很容易通过时间序列识别出自动化程序。随机延时import random import time time.sleep(random.uniform(2, 5))每次等待 2 到 5 秒之间的随机值。这个方式模拟了人类浏览时的不确定性节奏更自然。实测下来随机延时的采集任务比固定延时的任务稳定很多。5.3 429 状态码的应对策略如果已经收到429说明服务端已经明确告诉你“请求太快了”这时候最忌讳的是立刻重试。正确做法是退避冷却休息一段时间再继续。指数退避的思路是第一次失败等 5 秒第二次失败等 10 秒第三次等 20 秒以此类推直到恢复。def connect_with_backoff(session, url, max_retries5): delay 5 for i in range(max_retries): resp session.get(url, timeout10) if resp.status_code ! 429: return resp print(f触发 429等待 {delay} 秒后重试) time.sleep(delay) delay * 2 return None收到429之后一定要冷静不要跟服务器较劲先把频率降下来再慢慢恢复采集。5.4 全流程限速设计除了单次请求的延时整个采集任务最好有一份限速方案。这个方案本身不复杂关键是要提前想清楚单页间隔普通商品详情页建议 2 到 5 秒。单批次数量一个批次最多采集 50 到 100 个商品链接跑完休息 5 到 10 分钟再跑下一批。每日总量根据业务需求控制在几百到几千的级别不要贪多。运行时段尽量避开业务高峰时段比如大促当天不要高频拉取。把这些参数直接配置在脚本里任何一次运行都不会超过预设的限速阈值。另外所有请求操作都打日志包括请求时间、状态码、耗时方便后续排障和调整频率。6. 从采集到分析价格监控与竞品对比的最小落地系统6.1 数据存储方案采集到的数据必须落地否则每次都从页面重新抓既浪费流量又容易触发限流。存储方案根据数据规模二选一。CSV 方案适合小规模数据、几十个商品以内的监控。写起来简单可以直接用 Excel 打开预览。import csv def save_to_csv(rows, filenameitems.csv): fieldnames [item_id, title, price, shop, crawled_at] with open(filename, a, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesfieldnames) if f.tell() 0: writer.writeheader() writer.writerows(rows)SQLite 方案适合长期积累、几百上千个商品、需要做历史价格回溯的场景。SQLite 既能支持 SQL 查询又不需要单独部署数据库服务。import sqlite3 conn sqlite3.connect(price_monitor.db) conn.execute( CREATE TABLE IF NOT EXISTS goods ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_id TEXT, title TEXT, price REAL, shop TEXT, crawled_at TEXT ) ) conn.execute( INSERT INTO goods (item_id, title, price, shop, crawled_at) VALUES (?, ?, ?, ?, ?), (item[item_id], item[title], item[price], item[shop], item[crawled_at]), ) conn.commit()长期跑下来SQLite 文件本身的体积很小但查询效率远高于 CSV尤其是要做“某个商品最近 30 天价格走势”这种查询SQL 一行就能搞定。6.2 价格历史与波动判断数据持续采集之后就能做价格波动分析了。最基础的两个指标是涨跌幅和历史最低价。import sqlite3 conn sqlite3.connect(price_monitor.db) def price_history(item_id, days30): cur conn.execute( SELECT crawled_at, price FROM goods WHERE item_id ? AND crawled_at datetime(now, ?) ORDER BY crawled_at ASC , (item_id, f-{days} days), ) return cur.fetchall()拿到价格序列之后可以计算当前价格相对第一次采集价格的变化幅度当前价格在历史区间内处于什么位置最近一次价格变动发生的时间点这些指标能直接输出成日报供选品或运营决策参考。6.3 竞品分析的几个实用指标价格监控做到位之后自然要往竞品分析方向延伸。基于采集到的结构化数据我常用下面这几个指标指标计算方式用途同款比价按商品标题相似度或 SKU 关联不同店铺的价格找出价格最低的店铺促销频率统计某个商品在一个月内价格变化的次数判断该店铺的调价策略上下架状态如果连续多天采集不到某个商品记录下架时间点判断竞品产品生命周期到手价对比结合优惠券信息计算实际到手价比表面价格更具参考价值比如同款比价最简单的方式是按title做关键词匹配匹配到同一批关键词的商品视为同款再横向对比不同店铺的价格差。这个逻辑不复杂但对选品和定价策略已经很有参考价值。6.4 定时运行与频率建议整套系统跑起来之后把它挂到定时任务里就能持续产生数据。Windows 环境使用“任务计划程序”定时执行 Python 脚本。Linux 环境使用crontab比如每天凌晨 2 点跑一次采集任务。频率怎么设置我的建议是普通价格监控一天 1 到 2 次就够了大促期间可以适当加密到每 3 到 4 小时一次但不要低于 1 小时一次。实际上商品的日常价格波动远没有想象中频繁一天两次基本能覆盖所有关键变化。频率太高只会增加风控风险并不带来额外的信息量。另外每个采集脚本最好加一个运行时长上限比如最多运行 30 分钟就自动退出。这样即使某个环节卡住也不会长时间空转影响定时任务的下一次执行。最后再分享一条我个人的体会这套系统真正难的不是写代码而是数据管理。早期我花了很多精力在请求和解析上结果采集到的数据没有统一的字段规范几个月后想拉价格趋势发现历史数据缺胳膊少腿完全用不上。所以无论你用的是 CSV 还是 SQLite从一开始就要把字段定义清楚、采集时间记录准确。数据质量永远比采集速度重要这也是整个价格监控系统能不能长期发挥作用的关键。本文还有配套的精品资源点击获取 
![【大模型RAG生成式AI开发实战】《大模型RAG生成式AI开发实战》_154.[第16章 提示词工程与RAG] Few-shot提示：在RAG中加入示例](http://pic.xiahunao.cn/yaotu/【大模型RAG生成式AI开发实战】《大模型RAG生成式AI开发实战》_154.[第16章 提示词工程与RAG] Few-shot提示：在RAG中加入示例)
