简介一份面向拼多多商家、MCN机构与电商运营者的实操型资源包围绕Anti-Content加密、订单采集、推广数据分析和财务流水等场景提供了可直接参考的代码与说明。资源共五个文件涵盖Python主程序、JavaScript辅助脚本、HTML测试页面、Markdown说明文档及依赖清单压缩包整体仅九十七KB轻量便于快速下载和部署。目前已有六百七十三人学习下载适合有一定电商或编程基础的运营人员用于理解拼多多数据对接逻辑和自动化处理流程。其中JavaScript脚本与HTML测试页面可辅助分析拼多多前端Anti-Content加密参数生成逻辑订单采集相关代码则提供了数据请求与解析的参考实现。通过阅读README和示例代码读者可以掌握订单数据抓取结构、推广效果统计方法、财务流水整理方式并结合店群与MCN业务场景进行二次开发从而提升多店铺运营效率和内容变现能力。1. 从店群订单采集到推广数据为什么绕不开Anti-Content加密做拼多多店群或者MCN数据汇总的人大概率都遇到过这类场景手上十几家店铺每天要拉订单、盯推广花费老板还会丢一句“今晚要看到报表”。一个一个进后台复制粘贴能撑到月初就算运气好。于是自然想到写脚本自动采集。可真正动手后发现开放平台API并不是你想用就能用去商家后台H5抓包又被 anti-content 这个加密参数挡在门外。这篇笔记就是围绕这个困局写的先把能走官方API走的通道讲透再补上H5接口里anti-content的生成思路最后把订单采集、推广数据拉取过程中最容易翻车的几个点挨个拆开。适合准备自建采集工具的店群运营、MCN数据开发以及想搞清楚“到底能不能做”的服务商朋友。2. 数据入口怎么选先看权限再看加密2.1 拼多多开放平台API能拿订单也能拿部分推广数据拼多多开放平台是目前唯一正规的数据入口。你需要先在开放平台注册应用拿到client_id和client_secret再通过 OAuth 流程让每个店铺绑定并授权你的应用。授权成功后会拿到该店铺的access_token后续所有订单、商品、推广类接口都要带着这个 token 调用。很多朋友第一次申请时会在“应用类型”这里卡住。自用型应用只能拉自己店铺的数据适合单店运营服务商应用可以同时管理多家店铺授权适合店群和MCN但审核要提交业务证明我见过不少人连续申请被驳回原因就是没有上传对应的服务商资质或合作案例。所以第一步先想清楚你到底是要给自己拉数据还是要给一批店铺做代运营。这个选择直接决定后面对接的复杂程度。权限是第二个硬门槛。订单类接口通常在自用型应用上就能开通但推广数据相关接口一般会单独校验“推广资质”。我在一个MCN项目中就遇到过这种情况订单接口调得很顺推广报表接口却一直返回“无权限”进开放平台后台一看权限包只勾选了“订单和商品”推广包是灰色的。这不是写代码能绕过的唯一办法是走权限申请流程或者换用商家后台H5接口做补充。另外还要注意 token 维护。开放平台会给每个授权店铺发独立的 tokentoken 不是永久的快过期时会下发refresh_token。店群场景下几十个 token 分散存到配置里如果没做自动刷新某天凌晨任务就会大面积失败。不要问我是怎么知道的。2.2 商家后台H5接口anti-content和rc-res-data在哪里当开放平台没有对应权限或者某个数据维度只有后台能看时只能回退到商家后台H5接口。打开开发者工具切到 Network 面板勾选 Fetch/XHR然后去后台点一次订单查询就会看到类似这样的请求https://mms.pinduoduo.com/order/xxx?anti-contentxxxxrc-res-data...timestamp...其中anti-content是请求签名rc-res-data是响应数据经过包装后的载体。每次请求的参数不一样签名也不一样。直接拿浏览器里的 URL 重放服务器会发现签名与参数不匹配然后返回“访问被拒绝”之类的错误。这就是很多新手第一次抓包后的困惑明明什么都有了为什么一跑脚本就歇菜。抓包时要关注的字段不只是anti-content。真正决定签名能否通过的是你提交的所有业务参数包括请求体里的 JSON 字段顺序。拼多多的H5接口对参数序列化顺序比较敏感我曾经因为把page_num放在page_size前面导致签名始终失败调了一晚上最后按请求体原顺序重排才通过。建议抓包时把完整的 query string 和 request body 都复制下来作为校验依据。2.3 入口选型我的默认路径和一条红线场景优先入口备选入口自营店铺订单采集开放平台APIH5订单接口少用多店店群订单汇总服务商API多tokenH5接口补充MCN达人推广报表开放平台推广APIH5商达报表开放平台无权限的维度不用H5限本人账号可见数据我的默认路径是订单和售后全部走开放平台API推广数据先试API权限能申请下来就不用H5只有诸如“达人带货明细”“直播间维度投放数据”这种后台独有报表才考虑H5。这么做是为了减少维护成本因为anti-content签名很可能随着后台改版而变那不是普通业务项目能耗得起的。红线只有一条不要用H5去抓取你自己账号权限之外的数据。anti-content解决的是“请求是否合法”的签名问题不等于授权。你看到多少采集多少这是基本边界。3. 用开放平台SDK拉订单和推广数据最小可跑代码3.1 申请应用、装好PHP SDK假设后端是 PHP我通常直接用开放平台官方SDK。搜索“拼多多开放平台 sdk包 php下载”能找到官方SDK也可以用 Composer 方式安装。装好后先写一个最基础的客户端初始化require vendor/autoload.php; use Pdd\Client\PddClient; // 以实际SDK命名空间为准 $client new PddClient([ client_id 你的client_id, client_secret 你的client_secret, ]);逻辑说明PddClient负责统一处理签名、请求发送和响应解析。构造参数只需要开放平台应用后台里的client_id和client_secret。access_token一般是在授权后获取每个店铺一个建议存数据库而不是写死在代码里。这里不展示完整OAuth流程因为开放平台有沙箱环境强烈建议先在沙箱里跑通授权回调。参数说明client_id和client_secret都是开放平台后台“应用信息”里的字符串不要暴露在前端代码里。redirect_uri需与申请应用时填写的回调地址保持一致否则授权时会跳转失败。3.2 拉订单增量订单接口的最小实现拼多多订单采集最常用的是“增量订单”接口接口名以开放平台文档为准。下面是核心逻辑$request new PddRequest(); $request-setType(pdd.order.list.increment.get); $request-setParams([ start_updated_at 2025-11-01 00:00:00, end_updated_at 2025-11-01 23:59:59, status 3, // 订单状态按业务需要调整 page_size 100, // 单页条数最大一般100 page_num 1, use_has_next true, ]); $client-setAccessToken($storeTokenMap[$storeId]); $response $client-execute($request);逻辑说明请求类型pdd.order.list.increment.get是增量订单查询返回的是指定更新时间范围内的订单列表。status字段决定只拉某类状态的订单比如待发货、已发货、已完成。实际店群里订单状态是流转的我通常不传status直接全量拉回来后在本地按状态归类避免漏单。参数说明start_updated_at和end_updated_at必须注意时间粒度。增量接口一般限制最大查询区间不要试图一次拉一个月正确做法是把一天拆成多个时间段循环请求。page_size填 100 是常规值太大容易触发请求频率保护。use_has_next传true通过响应里的has_next判断是否继续翻页。3.3 拉推广数据同一套SDK换接口名和参数推广数据接口不同账号命名的差异可能比较大我这里用常见的pdd.ad.mall.report.get作为示例实际接口名以你开放平台后台开通的权限点为准$request new PddRequest(); $request-setType(pdd.ad.mall.report.get); $request-setParams([ start_date 2025-11-01, end_date 2025-11-07, page_size 100, page_num 1, dimensions [mall], // 按店铺维度汇总 ]); $client-setAccessToken($storeTokenMap[$storeId]); $response $client-execute($request);逻辑说明推广报表和订单接口最大的区别在于“没有实时性要求”。订单接口要关注增量推广报表更多是按天拉取汇总数据。dimensions决定报表粒度MCN场景下可能需要按“达人”维度这时传[inviter]具体枚举要看接口文档。推广数据返回里通常会有曝光、点击、花费、成交金额等字段建议先把响应打印一次记录字段名再落库。参数说明start_date和end_date用日期字符串不要带时分秒。dimensions的值是 JSON 字符串如果你直接传 PHP 数组会报类型错误必须先json_encode。另外推广报表接口的分页参数往往也叫page_num/page_size但有一部分报表接口只支持offset/limit调用前仔细看文档。3.4 落库订单和推广数据怎么对账采集完数据只是第一步落库才是店群系统真正的核心。订单和推广数据需要对齐到同一家店铺、同一天CREATE TABLE pdd_order_daily ( store_id VARCHAR(32), stat_date DATE, order_count INT, paid_amount DECIMAL(12,2), PRIMARY KEY (store_id, stat_date) ); CREATE TABLE pdd_ads_daily ( store_id VARCHAR(32), stat_date DATE, spend DECIMAL(12,2), pay_amount DECIMAL(12,2), PRIMARY KEY (store_id, stat_date) );逻辑说明两张表都以store_id stat_date作为联合主键方便后续做订单金额和推广花费的对账。订单金额取“买家实付金额”推广花费取“实际消耗”两者相加应该与店铺整体业绩报表近似相等。如果对不上大概率是订单状态过滤或者推广数据单位换算出了问题。4. 理解Anti-Content从抓包到本地重放4.1 还原一次H5请求需要哪些字段开放平台没权限时H5接口的抓包就变成了唯一线索。以订单查询页为例一次完整请求通常包含参数作用备注timestamp请求时间戳签名必须和这个时间戳一致anti-content请求签名由业务参数和时间戳生成rc-res-data响应数据载体响应里主要的内容包ver版本号部分接口会随版本变化第一次还原时不要贪多先选定一个最简单的查询请求把它的完整URL、请求头、请求体保存下来。然后试着去掉anti-content直接重放观察返回的错误码。这一步能帮你确认它是不是硬校验。4.2 生成anti-content的通用思路anti-content 本质上是一个签名串。常见的生成步骤是把业务参数按 key 升序排列拼接成类似key1value1key2value2的字符串再混入一个固定盐值和请求时间戳最后做一次 MD5 或 HMAC-SHA256。具体是哪种哈希、盐值是什么只能通过调试页面里的 JS 文件确认。这里给一个通用模板import hashlib import time import json def gen_anti_content(params: dict, timestamp: int None): ts timestamp or int(time.time()) params dict(params) params[timestamp] ts # 1. 按 key 升序排列值统一转字符串 raw .join( f{k}{params[k]} if isinstance(params[k], str) else f{k}{json.dumps(params[k])} for k in sorted(params.keys()) ) # 2. 追加密钥片段具体盐值需要从JS里找 raw secretpdd_mms_secret # 3. 做摘要后转大写再和时间戳拼接 sign hashlib.md5(raw.encode(utf-8)).hexdigest().upper() return f{ts},{sign}逻辑说明这个函数的关键点是“参数排序”。sorted(params.keys())保证签名时参数顺序稳定不会受请求体里字段顺序影响。params[k]如果是嵌套对象用json.dumps序列化否则直接拼字符串。最终返回的timestamp,大写摘要是很多网页签名共用的格式。参数说明secret是我占位的示例真实盐值通常藏在混淆后的 JS 文件里需要通过断点调试找到。不要幻想在完全没有浏览器环境的条件下凭空猜出盐值最稳的做法是用 Playwright 拦截页面里真实发出的 anti-content 做对照。4.3 用Python在本地跑通一个查询请求有了签名函数还需要一个能维护登录态的请求客户端。拼多多后台是 Cookie 登录可以先把浏览器里的 Cookie 复制到本地文件里import requests import gen_anti_content # 上面那个函数 with open(cookies.txt, r) as f: cookie_str f.read().strip() params { page_no: 1, page_size: 20, order_type: pdd, } ts, sign gen_anti_content(params) params[anti-content] sign params[timestamp] ts url https://mms.pinduoduo.com/order/query resp requests.get(url, paramsparams, headers{ User-Agent: Mozilla/5.0 ..., Cookie: cookie_str, }) print(resp.text)逻辑说明请求发送时查询参数里同时带上业务参数、timestamp和anti-content。注意timestamp必须和生成签名时用的保持一致不能先生成签名再等两秒发送那样服务器会判定时间偏差。Cookie也可以用requests.Session()来维护这样能保留登录状态减少重复登录。参数说明page_no和page_size是页面端常用的分页名具体以后台抓包为准。order_type是业务筛选条件这里只是演示真实字段名需要看请求体结构。User-Agent也建议保持一致不要默认的python-requests不然风控容易拦截。4.4 用Playwright做对照减少密钥还原成本还原盐值这件事比较耗时。如果你的需求只是每天固定拉几次数据还有一个低成本方案直接用 Playwright 启动浏览器登录后台后拦截接口响应不自己生成签名。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://mms.pinduoduo.com/login) input(请手动登录后按回车继续...) def on_response(resp): if /order/query in resp.url: print(resp.url) print(resp.text()) page.on(response, on_response) page.goto(https://mms.pinduoduo.com/order/list) page.wait_for_timeout(10000)逻辑说明手动登录一次浏览器会携带真实 Cookie。页面上的接口响应会实时打印出来你可以把这些响应存成 JSON 文件再解析。这种方式的优点是签名完全由页面自身生成不用逆向 JS缺点是要占用一个浏览器进程而且每次运行需要人工介入登录。适合低频报表采集不适合大规模店群自动化。5. 避坑订单采集和推广数据里的5个翻车点5.1 订单漏采报表数字对不上现象每天订单表里少了几十单但后台页面上明明有这些订单。原因增量订单接口的时间窗口不是你想的那样。它查的是“订单更新时间”不是“下单时间”。用户拍下后修改地址、改备注、客服在后台做任何操作都会把订单推到“已更新”队列里。如果只按下单时间切分增量区间那些在区间内被更新但下单时间在区间外的订单就漏掉了。解决把更新时间和下单时间分开维护。采集任务统一按“更新时间为准”拉到本地后再用order_sn做去重以“最后一次更新时间”作为覆盖标准。这样即使一个订单被反复更新也不会重复入账。5.2 开放平台返回“缺少参数”现象同一个接口文档上的示例参数全传了却一直报缺少 XX 参数。原因拼多多开放平台的参数名是大小写敏感的。常见翻车点有page_num写成pageNumstart_updated_at写成startUpdatedAt。接口内部会严格按文档里的参数名取数找不到就直接报缺参。解决推荐把每个接口的请求参数映射表写成一个 PHP 数组或 JSON 配置文件键名严格按文档复制不要自己驼峰化。我在项目里给SDK包了一层参数映射每次调用接口前自动做命名转换能少踩很多坑。5.3 推广数据花费对不上账现象推广报表里的“花费”和店铺后台页面显示的花费差了几十倍。原因很多推广报表字段单位是“分”页面显示时做了元换算。如果你把接口返回的数值直接落库就会把一分钱当成一块钱。解决字段落库前统一除以100并且把字段名改成spend_yuan。另外转化率在接口里可能是字符串形式比如2.5%落库时要转成0.025的DECIMAL不然后面对账只能靠肉眼看。5.4 anti-content生成后依然403现象签名函数跑通了但请求返回403或“签名失效”。原因最常见的是时间戳不一致。我先用time.time()生成了签名然后在请求参数里又传了一个新的 timestamp两者相差一秒就校验失败。另一个原因是请求体序列化顺序和页面端不一致页面端把 JSON 数组转成字符串后可能做了 URL 编码而你没有。解决用同一个 timestamp 变量生成签名并发送。对于序列化差异建议先输出“签名前字符串”和浏览器JS端拼接的字符串逐字对比看到底是布尔值转成了true还是数组多了空格。5.5 触发滑块验证码整批任务停掉现象跑了几分钟采集任务后台页面弹出滑块验证或者所有请求都开始返回“人机验证”。原因同一 IP 在同一时间对拼多多频繁请求触发了风控。开放平台API一般不会要求滑块但H5接口会。解决给每个店铺独立配置采集频率同一IP同一秒不要超过 1-2 个请求。遇到滑块时不要尝试自动过验证直接停止当前队列等待一段时间再继续。我现在的方案是把店铺任务分散到不同时段执行比如店铺A跑上午店铺B跑下午错峰之后滑块出现频率明显降低。6. 店群与MCN场景下的进阶调度让采集自动化闭环6.1 用队列控制多店铺采集频率店群场景下几十个店铺共用一套采集服务是常态。我习惯把每个店铺的采集任务塞进 Redis 队列队列消费时带上店铺维度的时间锁。同一店铺的订单采集任务必须等上一次跑完才能进下一次避免同一个 token 并发调用触发频控。MCN 场景则反过来按达人分组每组一个独立队列方便单独控制拉取频率。6.2 对账SQL每天出报表前先自检采集完订单和推广数据后我会跑一遍对账SQL再决定是否给运营发日报SELECT store_id, stat_date, SUM(IFNULL(o.paid_amount, 0)) AS order_amount, SUM(IFNULL(a.spend, 0)) AS ad_spend FROM pdd_store_base b LEFT JOIN pdd_order_daily o USING (store_id, stat_date) LEFT JOIN pdd_ads_daily a USING (store_id, stat_date) WHERE stat_date CURRENT_DATE GROUP BY store_id, stat_date;这张查询会列出每家店铺的订单金额和广告花费。正常情况下推广花费不应该超过订单毛利的 30% 左右如果某天对不上优先去看订单是否漏采、推广数据是否除以100。6.3 我的一个习惯我现在的习惯是能走开放平台API的绝不碰H5必须碰H5时只做低频补充采集。这个习惯帮我避开过不少半夜被风控叫醒的场面。拼多多的接口和签名机制会变但数据仓库的对账逻辑不会变把功夫下在数据落地上更划算。希望帮到你。本文还有配套的精品资源点击获取