★ FEATURED ARTICLE 手里有大几十甚至几百个商品的卖家应该都有过这种崩溃时刻要在后台一页页翻商品、复制标题、记价格、查库存最后黏进Excel里已经花掉一个下午。我接手店铺数据自动化之后做的第一件事就是用拼多多开放平台API把店铺所有商品列表完整拉下来做成定时任务每天自动同步。这篇把我踩过的坑和最终跑通的完整方案都写出来适合想自己动手的开发者也适合做店铺工具的团队参考。先说个整体链路后面每一环都会展开注册开发者账号、创建应用、申请接口权限、拿到店铺授权token然后按签名规则封装请求用分页把全量商品拉下来最后落到自己的数据库。听起来步骤不少但真正卡住人的通常只有两处签名验签和分页边界。这两处我会重点讲。1. 抢在爬虫前头为什么商家后台的复制粘贴迟早得换成API1.1 商家后台手动导出商品数据痛在哪儿我最早接触这个需求是帮一个做店铺运营的朋友整理活动报名表。他要从后台手动导出商品再按销量排序、筛选在售商品、补上价格和库存最后做成一份提报表。商品数量少的时候还好几百个商品之后就明显扛不住了后台导出有数量限制文件名是乱码Excel打开要等半天数据里还混着已经下架的商品得手动一条条核对状态。后来我发现这类需求根本不是个例。常见的场景包括每天想监控店铺价格、销量变化但后台没有批量导出接口只能截图或者复制。做活动选品时要用多个维度筛选商品后台筛选条件不够细。商品数量上千后手工维护 SKU 和编码基本靠运气经常对不上。想给自己的小程序、ERP 或数据看板同步商品数据没有稳定数据源。这些需求有一个共同点都需要一份结构化、可定时获取的商品全量数据。后台的“复制粘贴”能解决一次两次但解决不了持续、自动、可控这三个要求。1.2 开放平台API和爬虫、RPA的本质差距很多人的第一反应是写爬虫或者用 RPA 工具模拟点击。我也都试过结论是能用但都是短期方案。爬虫最大的问题是需要处理登录态、滑块验证码、风控策略今天能跑通的脚本明天可能就拿不到数据。更麻烦的是爬下来的数据格式不稳定页面改版一次解析代码就得重写。RPA 看起来稳定但本质是模拟人在屏幕上操作只要页面布局变一点坐标就错位维护成本并不低。开放平台 API 走的是官方通道数据结构固定字段说明清楚权限可控也不容易出现账号风控问题。对比下来差异很明显方案数据稳定性开发成本合规风险可扩展性后台截图/OCR低低高差爬虫中中高中RPA 模拟点击中中中中官方开放平台API高中低强尤其当你打算把商品数据同步到自己的数据库里长期使用API 几乎是唯一值得投入的方案。接口返回的是纯结构化的 JSON字段名、类型都写得很清楚入库之前只需要做好映射。1.3 这条API调用链路解决了哪些真实场景我实际跑过的项目里这条链路主要解决了三个场景第一是定时快照。每天凌晨跑一次全量同步把店铺商品的价格、库存、销量状态存下来做历史趋势分析。第二是初始全量导入。新系统上线时把后台几千个商品一次性拉进本地库再建索引和搜索。第三是同步给下游系统。比如公司内部的价格审批系统、客服系统需要商品信息通过 API 拿到的数据能直接推给它们不用人工二次录入。后面几节我按照实际开发顺序来写先准备应用再做签名请求再处理分页最后落库。按这个顺序走通就能搭一个能用的商品同步任务。2. 开通前的整套准备工作应用创建、接口权限与access_token2.1 注册开发者账号并创建应用访问拼多多开放平台首页用商家账号登录进入开发者后台。如果是个人开发注册开发者时按提示完成实名认证就行如果是以公司名义提供服务流程类似多一个主体信息提交。登录后第一件事是创建应用。开放平台应用通常分自用型和工具型自用型应用是给自己店铺用的工具型应用是给其他商家提供服务的。自己拉自己店铺的数据创建自用型应用就够用接口权限申请路径也短很多。创建完成之后最重要的两个凭证是client_id和client_secret。注意client_secret只在创建时完整展示一次一定要马上复制保存到安全的地方。不要把密钥直接提交到公开代码仓库建议放到环境变量或单独的配置文件中。开发和测试环境可以用一套应用生产环境最好单独一个应用方便统计调用量和定位问题。这点很容易忽略。我之前有个项目把密钥写在代码里后来仓库权限被放宽不得不全部重置非常被动。2.2 申请获取商品列表接口权限和配额创建应用之后开放平台后台的“接口权限”或者“API 管理”页面里可以搜索商品相关的接口例如pdd.goods.list这类商品列表接口。不同时期接口名称可能调整我习惯按“商品 / 获取商品列表”这类关键词在文档区搜索确认最新的接口名。找到之后点击申请权限。有些接口是即时开通有些需要平台审核。审核通过前接口调用会报“无 API 权限”或者“权限不足”这个不用慌去权限列表里看状态就行。还要留意接口的配额。开放平台对每个接口通常有调用频率限制比如每分钟多少次、每天多少次。商品列表这类接口的配额通常够日常同步使用但如果要一次性初始化几万条商品还是得做频率控制后面第 5 节我会给具体的参考做法。2.3 拿到access_token授权流程与刷新机制获取店铺商品列表通常需要店铺授权也就是在调用接口时带上access_token。整个授权流程走的是常见的 OAuth 授权码模式在应用配置里填好回调地址redirect_uri一般是 https 开头。拼接授权页面 URL参数包含client_id、redirect_uri引导商家跳转。商家在授权页确认后平台会带上一个code跳回到回调地址。后端拿code换取access_token和refresh_token。换 token 这件事很多开发者第一次做都会懵。一个简单的示意逻辑大致是这样# 假设已经从回调参数里拿到了 code def exchange_token(client_id, client_secret, code, redirect_uri): params { client_id: client_id, client_secret: client_secret, code: code, redirect_uri: redirect_uri, # 具体接口名以开放平台文档为准 type: pdd.pop.auth.create, } # 加上签名后发起请求 resp requests.get(API_GATEWAY, paramsparams, timeout10) data resp.json() return data.get(access_token), data.get(refresh_token)这里有几个容易踩的细节access_token不是永久有效的过期之后需要拿refresh_token重新换所以刷新逻辑要写进定时任务里。回调地址必须和后台配置的完全一致包括协议和路径否则授权会失败。换到 token 之后先手动调用一次商品列表接口验证确认能返回数据再进下一步开发。3. 签名不通过八成是这里出了问题请求封装与验签细节3.1 拼多多POP网关的签名规则拆解拼多多开放平台的签名规则是我见过最容易引起困惑的地方之一。官方网关对每个请求都会校验sign参数签名算法按下面的步骤来把所有请求参数除了sign自己按参数名字母 ASCII 升序排列。把参数名和参数值直接拼接成一个字符串中间不加或比如client_idabc123timestamp1700000000typepdd.goods.list。在拼接好的字符串前后各加一次client_secret。对最终字符串做 MD5 加密再转成大写就是sign。没写错确实不是常见的key1value1key2value2格式而是纯keyvalue首尾相连。我第一次写的时候惯性用了带和的拼接方式结果怎么验签都过不了。需要注意部分平台的文档可能要求参数值先做 URL 编码再参与签名。拼多多当前的规则是直接拼接原始值但接口文档可能更新稳妥的做法是在官方调试工具里调一次把自己的参数和签名结果手工算一遍看是否一致。3.2 用Python封装一个通用请求方法签名和请求封装可以放在一个文件里这样后面加其他接口也方便。下面是我项目里用的简化版本import hashlib import time import requests API_GATEWAY https://gw-api.pinduoduo.com/api/router def make_sign(params: dict, client_secret: str) - str: 生成拼多多开放平台签名 # 过滤掉 sign 本身 filtered {k: v for k, v in params.items() if k ! sign} # 参数名按 ASCII 升序排列 sorted_keys sorted(filtered.keys()) # 拼接成 keyvalue 格式 raw_string .join(f{k}{filtered[k]} for k in sorted_keys) # 首尾各加一次 client_secret raw_string client_secret raw_string client_secret # MD5 并转大写 return hashlib.md5(raw_string.encode(utf-8)).hexdigest().upper() def pdd_request( client_id: str, client_secret: str, access_token: str, api_type: str, business_params: dict None, ): params { client_id: client_id, access_token: access_token, timestamp: int(time.time()), type: api_type, } if business_params: params.update(business_params) sign make_sign(params, client_secret) params[sign] sign resp requests.get(API_GATEWAY, paramsparams, timeout10) resp.raise_for_status() return resp.json()这个封装把公共参数和业务参数合并到一起统一生成签名再用 GET 请求发出去。如果接口文档要求部分参数必须 POST可以在这个基础上去调整但签名部分的逻辑是通用的。补充一点实际返回体可能是包裹结构比如{goods_list_get_response: {...}}打印出来之后按实际结构去取值就行。不要假设每个接口都直接返回平铺 JSON。3.3 常见验签报错与逐项排查签名不过是最常见的失败原因。我整理了一份自查顺序报错现象可能原因处理建议invalid_sign/ 签名错误参数拼接格式不对漏了某个公共参数参与排序的 key 顺序不对打印出raw_string对照文档逐步核对参数不合法 / 缺少必要参数接口名写错必填业务参数缺失回接口文档重新核对参数名注意大小写timestamp过期服务器时间偏差太大用时间同步服务校准系统时间无 API 权限接口权限未申请或还在审核去开放平台控制台看权限列表access_token无效token 过期或未完成店铺授权重新走授权流程并实现刷新逻辑我排查签名问题时最常用的办法是在本地把最终的raw_string打印出来再和官方调试工具里的参数做对比。大多时候都是参数名大小写不一致或者漏了access_token很少真的是算法问题。4. 翻页才是所有商品列表的关键分页策略与字段说明4.1 商品列表接口的分页参数与返回结构调用商品列表接口时常见的分页参数是page页码和page_size每页数量。不同版本的接口文档可能用page_num所以写代码前先确认一下。每页条数一般有上限建议先看文档说明不确定时就保守一点用 50 或者 100 都行。一个典型的读取逻辑是def fetch_all_goods(client_id, client_secret, access_token): page 1 page_size 100 all_goods [] while True: data pdd_request( client_id, client_secret, access_token, api_typepdd.goods.list, business_params{ page: page, page_size: page_size, }, ) goods_list extract_goods_list(data) # 按实际返回结构解析 total_count extract_total_count(data) # 按实际返回结构解析 all_goods.extend(goods_list) # 当已拉取数量 总数时结束 if page * page_size total_count: break page 1 time.sleep(0.3) # 控制请求频率 return all_goods这里的extract_goods_list和extract_total_count是占位函数实际需要根据接口返回结构调整。第一次跑的时候建议打印一页完整响应把字段层级看清楚了再写解析逻辑这是最省时间的做法。4.2 增量/全量拉取的分页策略设计“店铺所有商品列表”听起来是一次性拉取但实际使用中至少有两种模式全量模式适合初始同步。第一次建库时把所有商品全部拉下来后面每天再定时重跑。商品数量在几千以内这种模式完全够用其中要注意的就是退出循环的边界条件。常见的问题是把结束条件写成while len(all_goods) total_count这样一旦接口返回重复商品就可能死循环。用page * page_size total_count更稳。增量模式适合频繁更新。如果接口支持按更新时间筛选比如传update_start_time、update_end_time就可以只拉最近修改过的商品。如果接口不支持时间筛选那就只能全量拉取后在本地做主键对比本地表里已有的商品做更新没有的新增已经下架的根据状态字段做下架标记。还有一种情况是接口分页超过一定页数后不再允许翻页或者返回空数据。遇到这类限制就不能单纯靠页码循环要么改用时间窗口分段拉取要么接受只在凌晨任务里跑一次。我在实际项目里就碰到过翻到几百页之后返回空列表的情况当时改成按“状态更新时间”拆分成多个子任务才绕过去。4.3 核心商品字段映射从接口字段到业务字段商品列表接口返回的字段通常比后台导出更丰富。常见的核心字段大致有这些接口字段含义入库建议goods_id商品唯一 ID主键goods_name商品标题业务展示字段goods_sn/outer_goods_id商家自定义编码对接 ERP 用thumb_url商品主图存 URL 还是下载图片按需决定normal_price销售价注意单位是“分”还是“元”market_price市场价/划线价同上sold_quantity累计销量用于选品排序status商品上下架状态状态码含义一定以文档为准尤其要留意价格单位。很多电商开放平台为了防止小数精度问题价格字段返回的是整数分也就是999表示 9.99 元。入库前如果不做转换后面做价格对比和分析就会错得一塌糊涂。我自己的习惯是先看文档里对字段类型的说明如果写的是Long而且示例值带_分后缀就先转成元再入库如果文档不明确就先拉一个真实商品数据看一眼再决定。5. 数据落地建表与八条高频踩坑清单5.1 商品表结构设计建议拿到商品列表之后下一步自然是入库。表结构不需要一开始设计得特别复杂但要给后续留点余地。我常用的商品快照表大致长这样CREATE TABLE product_snapshot ( product_id BIGINT PRIMARY KEY COMMENT 商品ID, product_name VARCHAR(255) COMMENT 商品标题, outer_goods_id VARCHAR(64) COMMENT 商家自定义编码, image_url VARCHAR(512) COMMENT 商品主图链接, price BIGINT COMMENT 价格按接口文档单位存储, market_price BIGINT COMMENT 市场价按接口文档单位存储, sold_quantity INT COMMENT 累计销量, status_code INT COMMENT 商品状态码, sync_time DATETIME COMMENT 同步时间, KEY idx_sync_time (sync_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品同步快照表;这里有几个实用考虑价格字段直接存整数单位统一避免浮点数比较误差。如果需要展示成“元”在查询时除以 100 或 1000具体取决于接口单位。sync_time加上索引方便做时间回溯和增量排查。如果同一店铺天天快照这张表会越来越大。建议要么定期清理历史数据要么改成“当前数据表 历史快照表”两张表的结构。当前数据表只保留最新状态快照表按天归档。5.2 八条高频踩坑记录表这段内容是我实际跑项目时积攒下来的按出现频率排序坑现象解决办法接口权限没申请调用报无权限看清接口权限状态商品列表接口需要单独开通签名参数漏配一直报签名错误把公共参数完整列全别漏access_token分页起始搞错第一页数据丢失或越界确认page从 1 开始还是从 0 开始每页条数超过上限返回条数达不到预期按文档填page_size超了会被截断价格单位搞错价格放大或缩小先打印一条样例确认单位是分还是元token 过期凌晨任务突然失败定时刷新 token或失败后自动重试刷新状态码含义不清上下架商品混淆对照文档确认状态码建议保存一份枚举映射请求频率过高被限流或返回异常每页之间 sleep 0.2~0.5 秒失败做退避重试有些坑表面上看是网络问题实际是前一步埋下的。比如分页越界后返回空列表会让程序误以为商品拉完了而实际上中间漏了很多页。这种问题最难查因为日志里看不到报错只看到数据偏少。排查办法是比对总数total_count和实际拉到的条数不一致就说明分页逻辑有问题。5.3 限流、风控与数据一致性建议做定时同步比功能更重要的其实是节奏。几个建议供参考定时任务频率不要太密。每天凌晨跑一次全量同步通常足够如果确实需要更频繁间隔至少 5 分钟以上。初始化大批量拉取时每页之间加time.sleep(0.3)避免在一个窗口期内打满配额。遇到网络超时或 5xx 错误不要立刻重试指数退避比较稳比如 1 秒、2 秒、4 秒这样逐步拉开。每次同步记录一份任务日志至少包含开始时间、结束时间、拉取总数、失败次数。没有这个日志出了问题就只能盲猜。数据一致性方面建议采用“先清空再插入”以外的策略。我是用主键冲突更新拿到的商品列表逐条插入快照表已存在就更新已下架的商品通过状态码标记而不是直接删掉历史记录。这样便于追踪商品什么时候下架、什么时候改价。最后说一个我自己的习惯接到这类接口任务时我不会先去设计表而是先跑通一页请求、把返回的 JSON 样例整个存下来再对照字段建表。业务字段宁愿先多留几个冗余列也不要等到上线后发现缺字段又要改表。这套方案我在三个不同店铺场景里都用过从第一次建应用到稳定同步商品数据基本一天内能跑通。如果你卡在签名或分页上把报错信息和返回样例打出来逐行比对多半能自己解决。
阅读完成 · 觉得有帮助？
