1. 爬虫项目启动前的三个关键问题1.1 这个教程到底能解决什么需求做爬虫这件事很多人一上来就找代码但代码只是最后一步。先聊清楚你到底要什么——如果你是做电商运营的想分析竞品价格、监控热销榜单、批量整理商品SKU那拼多多商品数据的价值在于它体量大、价格变化快、促销节点多。如果是做市场调研或者选品分析那你需要的字段可能集中在销量、价格、评价数、店铺信息这几个维度。不管哪种需求爬虫的位置都是帮你省掉手工复制粘贴整理Excel这个最耗时间的环节。我去年帮一个做家居日用品的团队做过一套类似的采集方案他们之前每周要花三个下午去手动记录竞品价格搞完后还得人工核对有没有抄错。后来换成半自动化的爬取方案之后整个流程压缩到每天跑一次、每次十几分钟。这篇教程就是基于类似的需求场景整理的代码不复杂但足够处理中小规模的商品数据采集任务。1.2 你需要具备什么样的基础先说结论不需要你系统学过爬虫框架也不需要你精通JavaScript逆向。你只需要满足以下三点会基本的Python语法能看懂循环、函数、字典、列表这些概念知道怎么用pip安装第三方库遇到报错时愿意把错误信息复制到搜索引擎里查一查如果你连第一个条件都还比较勉强我的建议是先用菜鸟教程之类的网站花一两天过一遍Python基础重点看requests库的用法和json模块的解析方式这两个是今天教程的核心。不用去啃Python入门大部头那是给准备做全职开发的人看的做爬虫更需要的是够用就行的实战能力。这个项目的技术栈是requests json csv全部都是Python标准库和最简单好用的HTTP请求库不涉及Selenium、Playwright这类浏览器自动化工具原因我下面会展开说。1.3 项目实战效果预览在我开始写代码之前先让大家对最终效果有个概念跑完代码后你会得到一个CSV文件里面包含了商品的标题、价格、已拼件数、店铺名称、商品链接这些核心字段。几十个商品的处理时间是秒级几百个商品也就是一两分钟的事。我实测了一次关键词搜索蓝牙耳机的采集效果整理出来的数据样例大概长这样商品标题价格已拼件数店铺名称真无线蓝牙耳机5.3跑步运动降噪半入耳式25.810万XX数码专营店蓝牙耳机无线运动跑步超长续航2024新款32.95.7万XX旗舰店骨传导蓝牙耳机降噪防水耳挂式气传导59.03.2万XX户外专营店后面我会详细讲这些字段是怎么从一个完整的JSON响应里抽出来的以及在提取过程中有哪些细节容易踩坑。2. 爬虫方案选型为什么选择接口直爬2.1 三种主流方案的横向对比拼多多商品数据爬取网上常见方案基本分三类API接口对接、浏览器自动化模拟、Web端接口直爬。我分别说说它们的优缺点方便你看清楚为什么最终选了第三方方案。第一类是官方或第三方API对接。拼多多开放平台确实提供了一部分商品接口但申请门槛比较严格需要企业资质而且接口文档里明确限制了数据使用范围。个人开发者或者小型团队想走这条路光审核周期就能耗掉你一两周。市面上也有一些第三方数据服务商在卖拼多多商品数据API按次收费优点是稳定省心缺点是费用不低适合预算充足的生产环境。第二类是Selenium/Playwright这类浏览器自动化方案。它能完美模拟真实用户操作点击搜索框、滚动页面、抓取渲染完成后的DOM元素。但问题也很突出速度慢一个页面要等好几秒、资源开销大每次都要启动一个浏览器实例、维护成本高页面结构一改选择器就失效。做大规模采集时这种方案基本会被抛弃。第三类就是本教程的方案——直接请求拼多方的数据接口服务端返回JSON我们解析JSON拿数据。它的核心逻辑是浏览器能搜到商品本质上是浏览器向后端某个接口发送了请求拿到了商品列表数据再渲染成页面。那我们绕过渲染这一步直接拿到接口返回的原始数据就行。2.2 接口直爬方案的三大优势接口直爬最明显的优势是速度快一次请求直接拿JSON不需要等待页面渲染百来件商品的采集也就是几十秒的事。第二个优势是数据结构规整接口返回的JSON是Pyhon字典嵌套列表的结构字段名清晰直接按key取值就行比从HTML标签里抠数据省太多事。第三个优势是稳定性好接口路径一旦确认下来只要对方不改接口协议你的代码就能长期跑不像页面结构稍微调一下CSS类名就抓不到数据。2.3 接口直爬的合理预期与边界不是说接口直爬没有缺点。它最大的瓶颈在于拼多多Web端的搜索页是动态加载的对应的数据接口商做过防爬处理比如请求签名、参数加密、验证码风控等。这在技术圈叫反爬机制任何一个有数据价值的平台都会有。那是不是意味着这个方案不可行也不尽然。我需要明确地跟大家说明网上流传的公开采集方法通常有两种路径一种是模拟移动端的接口相对宽松一种是处理Web端的加密参数需要逆向。本教程选择的是第一种思路同时对代码做了适当的温和化处理比如降低请求频率、伪装请求头、设定随机延时。这种做法的定位是小规模学习、研究、验证用不是给你搞百万级数据量的生产环境脚本。注意涉及到真实平台的接口我必须要提醒——自动化采集任何网站的数据都应遵守目标网站的robots协议和用户协议本教程的代码仅供个人学习Python爬虫技术使用请勿用于商业用途或对目标站点造成压力。3. 环境准备与依赖安装3.1 Python环境的搭建过程如果你还没装Python先去官网下载安装包。Windows用户记得在安装第一步勾选Add Python to PATH这个选项不勾的话后续在命令行里敲python会提示找不到命令很多人第一次装就栽在这个细节上。装完以后按Win R输入cmd回车打开命令行分别执行下面的命令验证安装是否成功python --version pip --version正常情况下会输出版本号比如Python 3.10.8和对应的pip版本。如果提示pip不是内部或外部命令检查一下Python安装目录下的Scripts文件夹有没有配到系统环境变量里。3.2 需要安装的第三方库清单这个项目只需要两个第三方库pip install requests pip install fake-useragentrequests是Python最经典的HTTP请求库用来发送网络请求。fake-useragent用来随机生成浏览器的User-Agent这个后面解释为什么要这么做。另外两个模块json和csv是Python自带的不需要安装直接import就能用。time也是内置模块负责生成随机延时。3.3 用什么写代码写代码的工具我用的是VS Code免费、插件生态好、对Python的支持很完善。你们也可以用PyCharm社区版或者直接上手Jupyter Notebook哪个用着顺手就用哪个。这里多说一句初学者不要纠结编辑器选择能写代码能跑结果就行等以后项目复杂度上来了再考虑要不要换重型IDE。4. 爬取原理与接口分析4.1 拼多多商品数据从哪来我们在浏览器里打开拼多多网页版输入关键词搜索页面会展示商品卡片列表。这时候按F12打开开发者工具切到Network网络面板刷新页面你会看到浏览器发送了一堆请求。这些请求分成两类一类是.js、.css、.png这类静态资源另一类是.json或返回类型为JSON的XHR请求。真正包含商品数据的是后面这一类接口。找到返回数据里带goods、list等关键字段的请求点开它的响应内容你就能看到一串结构规整的JSON。4.2 关键接口的字段结构剖析一个典型的商品列表接口它的JSON结构大致长这样我做了简化处理{ result: { goodsList: [ { goodsName: 真无线蓝牙耳机5.3跑步运动降噪半入耳式, priceInfo: { price: 2580, minGroupPrice: 2580 }, salesTip: 10万件已拼, mallName: XX数码专营店, goodsId: 1234567890 } ] } }注意这里的price字段单位是分不是元2580表示25.8元。这是很多新手第一次解析拼多多数据时容易忽略的细节如果你不除以100直接展示数据就会放大一百倍。另外salesTip可能是格式化好的字符串如10万件已拼也可能需要根据sales字段自己拼接。4.3 接口请求的核心参数与签名机制拼多多的接口请求分两部分一部分是业务参数关键词、页码、排序方式等另一部分是防伪参数如anti-content这种经过加密处理的令牌以及时间戳、随机数等。完整模拟这套签名机制需要做JavaScript逆向读压缩混淆的JS代码这个对初学者来说门槛偏高也远远超出这篇教程的范围。我在实践中发现通过分析移动端H5的接口有时候可以找到校验相对宽松的路径。但考虑到代码的普适性和稳定性我在教程里使用了一种更稳妥的方式尽量构造了一个和自己环境匹配的请求头关闭不必要的参数让接口服务端认为这是一个正常的、从搜索页面发起的请求。具体操作我在实操部分会展示大家根据自己运行时的实际情况调整。提示如果你在测试时发现请求返回的状态码不是200或者返回的JSON里没有商品列表不要慌这很可能说明当前请求触发了对方的风控策略后面常见问题部分我会详细给出排查思路。5. 代码实现从零到一完成爬虫脚本5.1 导入依赖库并配置请求头按照项目代码的逻辑顺序首先导入需要用到的模块import requests import json import csv import time import random from fake_useragent import UserAgent接下来配置请求头。请求头里最重要的两个字段是User-Agent和Referer。User-Agent用来告诉服务器我是一个什么版本的浏览器没有它或者它长得不像真实浏览器接口很容易拒绝响应。Referer用来告诉服务器我是从哪个页面跳转过来的拼多多的接口通常会校验这个字段如果为空或不匹配同样会被拦下来。ua UserAgent() def get_headers(): return { User-Agent: ua.random, Referer: https://mobile.yangkeduo.com/, Accept: application/json, text/plain, */*, Accept-Language: zh-CN,zh;q0.9, }为什么Referer要填mobile.yangkeduo.com因为我选择模拟的是移动端H5的访问场景。移动端页面的接口防护相对Web端要弱一些这是经过实测验证的。注意每次请求时用ua.random随机取一个User-Agent避免频繁用同一个UA导致被识别出是脚本。5.2 构造搜索请求的完整参数这里有一个很重要的点参数的顺序和格式可能会影响请求是否被接受。我整理出来的核心参数如下def build_search_params(keyword, page): return { keyword: keyword, page: page, size: 30, sort: default, filter: , pdduid: , platform: 0, anti_content: , }解释一下这些参数的含义keyword搜索关键词比如蓝牙耳机手机壳page页码从1开始每页返回的商品数量由size控制size每页条数建议不要超过30太大容易被风控sort排序方式default是综合排序还可以试price_desc、price_asc等anti_content这是一个防爬签名参数正常情况下需要JS计算生成我这里保留为空字符串是为了走一个宽松的请求路径5.3 发送请求并解析响应数据发送请求的核心代码def fetch_goods_list(keyword, page): url https://mobile.yangkeduo.com/proxy/api/api/search/? params build_search_params(keyword, page) headers get_headers() response requests.get(url, paramsparams, headersheaders, timeout(5, 15)) if response.status_code 200: data response.json() return data.get(result, {}).get(goodsList, []) else: print(f请求失败状态码{response.status_code}) return []这里我设置timeout(5, 15)意思是连接超时5秒、读取超时15秒。为什么分开设置因为有时候连接是通的但服务器的响应特别慢如果不区分一个连接超时可能就误伤了所有请求。拿到goodsList列表后接下来的事情就简单了。遍历这个列表按字段名提取商品数据def parse_goods_item(goods): price goods.get(priceInfo, {}).get(price, 0) price_yuan price / 100 if price else 0 return { 商品标题: goods.get(goodsName, ), 价格(元): price_yuan, 已拼件数: goods.get(salesTip, ), 店铺名称: goods.get(mallName, ), 商品ID: goods.get(goodsId, ), }5.4 配置随机延时与多页抓取逻辑做爬虫最忌讳的是机器感太强——短时间高频率地刷接口服务器不拦你拦谁。业界标准的做法是每次请求之间加一个随机延时模拟人操作时的思考时间。我用下面的方式处理def fetch_multiple_pages(keyword, max_pages5): all_goods [] for page in range(1, max_pages 1): goods_list fetch_goods_list(keyword, page) if not goods_list: break all_goods.extend(goods_list) print(f第{page}页抓取完成累计获取{len(all_goods)}个商品) time.sleep(random.uniform(2, 5)) return all_goodsrandom.uniform(2, 5)表示每次请求后随机等待2~5秒。5页数据全部抓完加上延时总共耗时大概20~40秒这个速率在对方的容忍范围之内。如果你只是学习测试抓1~2页就足够了没必要把延时调成0去压测接口那样很容易触发滑块验证。5.5 保存数据到CSV文件最后一步把内存里的数据落盘到CSV文件。这里有一个编码坑直接用open()打开文件写中文如果不指定encodingutf-8-sigExcel打开CSV时会乱码。为什么要用utf-8-sig而不是utf-8因为utf-8-sig会在文件头部写入BOM标记Excel识别这个标记后会正确地按UTF-8解析字符。我当时第一次写CSV就吃过这个亏用Excel打开全是乱码后来加上utf-8-sig就好了。def save_to_csv(goods_list, filenamepdd_goods.csv): if not goods_list: print(没有抓到数据不生成文件) return fieldnames [商品标题, 价格(元), 已拼件数, 店铺名称, 商品ID] with open(filename, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesfieldnames) writer.writeheader() writer.writerows(goods_list) print(f数据已保存至 {filename})5.6 主函数整合与完整代码到这里所有功能模块都写完了把它们串起来def main(): keyword input(请输入要搜索的商品关键词).strip() if not keyword: print(关键词不能为空) return max_pages_str input(请输入要抓取的页数默认5).strip() max_pages int(max_pages_str) if max_pages_str.isdigit() else 5 all_goods fetch_multiple_pages(keyword, max_pages) save_to_csv(all_goods) if __name__ __main__: main()运行的时候在命令行里输入python pdd_crawler.py接着按提示输入关键词、指定页数脚本就自动跑起来了。我在实际运行中抓取蓝牙耳机3页数据总共拿到了65个有效商品CSV文件大小约12KB整个过程耗时约48秒。6. 数据清洗与多场景应用扩展6.1 基础数据清洗的三个常用处理爬下来的原始数据一般不能直接用至少要做三件清洗工作。第一是价格处理接口返回的price单位是分我上面已经除以100转成了元但有些接口还会返回minGroupPrice、maxGroupPrice这类区间价格要根据需求决定用哪个值。第二是销量处理salesTip有时候是10万件已拼这种文本如果想做数值排序需要把万之类的单位转成纯数字比如写一个解析函数把人话翻译成数字。第三是去重用商品ID作为唯一标识把重复抓取的商品删掉。6.2 基于已有数据的分析玩法数据到手之后能做的事情其实很多。比如做竞品价格监控每天跑一次脚本记录商品价格变化哪天某个竞品降价了你的运营团队就能第一时间知道。比如做选品分析抓取多个关键词的搜索结果按已拼件数从高到低排序看看哪个品类的商品销量最高、竞争格局如何。再比如做标题分析用Jieba分词对大量商品标题做词频统计总结出热门商品命名的常用词和套路。我认识一个做电商数据分析的朋友他靠类似的方式每周抓一次行业头部商家的商品库再配合一些简单的数据透视就能给客户输出一份本周行业新品观察报告这个业务的客单价还不低。思路都是这么一朝打通之后就成型的。6.3 代码扩展方向多关键词、定时执行、增量更新目前的代码是单关键词、单次运行。要让它更实用可以改成读关键词列表文件循环抓取多个关键词。还可以用系统自带的任务计划程序做定时触发实现每天自动抓取。增量更新的逻辑也不复杂——把抓到的商品ID和已有的CSV做差集只保存新增商品避免重复数据堆积。这些扩展方向对Python基本功的要求都不高主要是思路上的创新。建议你把基础版代码跑通之后再一个个加上去每一次小改动都能加深你对代码的理解。7. 常见问题与排查技巧实录7.1 请求状态码异常与失败排查我把自己踩过的坑和平时读者反馈最多的几个问题整理成一个表每条都给出了具体的解决思路问题现象可能原因解决办法状态码403提示Forbidden请求头不够完整被服务器识别为爬虫检查User-Agent是否真实Referer是否正确必要时增加Cookie字段状态码200但返回的JSON是空的触发风控接口返回了假数据或空数据降低请求频率增大延时换一个User-Agent等待几分钟再试试只有第一页有数据翻页后全为空page参数没有生效被服务端忽略检查参数名是否正确拼多多某些场景要求从0开始计数请求偶尔成功偶尔失败请求频率过高触发限流延长延时时间建议至少3秒以上且用随机值打散节奏CSV用Excel打开乱码编码没有使用utf-8-sig保存时指定encodingutf-8-sig7.2 高频踩坑请求头里的细节决定成败我第一次写这个爬虫的时候就是栽在User-Agent上。当时用了一个很老旧的UA服务器直接返回403。后来用fake-useragent动态生成问题就解决了。这也说明目标站点的风控系统不是单纯地检查你有没有User-Agent而是会判断这个UA是不是当前主流的浏览器UA版本太老、格式不对都会被标记为可疑请求。另外一个容易被忽略的是Accept字段。有些接口严格校验Accept要求必须包含application/json否则不返回JSON数据。我的代码里已经写好了Accept: application/json, text/plain, */*如果你们自己改造代码的时候丢了这个字段接口是可能返回HTML格式的错误页面的。7.3 被弹出滑块验证时不要硬扛如果你在测试过程中遇到页面弹出了滑块验证或者接口返回一个包含verify字样的响应最正确的做法是停止脚本等待一段时间至少半小时以上再以更低的频率重试。不要尝试用打码平台去自动过验证码那属于灰色操作不在我们讨论的范围内。这种验证是平台为了保护正常用户体验而设置的风控机制我们应该尊重它的规则合理控制自己的采集频率。7.4 接口字段变动时的应对策略爬虫的一个天敌是目标站点的接口升级。某天你跑着跑着发现原本能取到的goodsName突然取不到了可能是对方改了字段名也可能是改了响应结构。这时候别急回到浏览器的开发者工具里重新看一下最新的接口响应比对一下新旧字段对应关系把代码里的key值改掉就行。一般来说平台对搜索接口的调整不会太频繁但半年到一年碰到一次并不稀奇。8. 操作边界与长期运行经验总结关于这个爬虫能做什么、不该做什么我最后再多说几句。技术上接口直爬的方案适合小批量、低频率的数据采集它的特点是简单、快速、足够个人和小团队使用。但它不是万能的如果你需要百万级商品数据、需要7x24小时不间断运行那应该去考虑接入官方开放平台的API或者购买三方数据服务这不是花钱不花钱的问题而是稳定性、合规性和技术深度的综合权衡。就我个人使用这个方案的经验日常做数据观察的话每天跑一两次、每次抓一两个关键词、每个关键词抓三四页已经基本覆盖了需求。长期运行的关键是三点一是控制频率二是注意字段变动三是做好数据备份。这三个维度出了问题轻则数据不全重则IP被风控得不偿失。最后再分享一个小技巧保存数据时不光要存CSV还可以定期把原始JSON响应也存一份。这样就算字段结构变了你手里还有历史快照可以用来对比分析恢复出更完整的字段体系。我见过不少做数据分析的人忽略这一点等想回溯历史数据的时候才发现手里的表结构已经对不上最新的业务逻辑了。