网友作品 #000071 · 提交于 2026/08/08
抖店数据采集插件：订单售后同步WPS多维表格
1 / 6
作品简介
这是一个 Chrome MV3 浏览器扩展，侧边栏即操作面板：点击图标展开，可查看订单、售后、直播概览三类任务的采集状态、最近结果与诊断日志。插件复用浏览器里已登录的抖店会话，通过注入页面的桥接脚本捕获真实接口后重放获取数据，再调用 WPS AirScript Webhook 写入 WPS 多维表格。加载未打包扩展即可使用，无需服务器，部署门槛低。
核心亮点
- 三类数据采集：订单、售后、直播概览，支持「最近 N 天」和「指定日期区间」两种模式
- 采集触发灵活：可配置时段自动定时采集，也可手动一键采集；页面未就绪自动打开/复用目标页并等待就绪
- 增量同步：本地 IndexedDB 保存上次上传快照，按售后状态、订单状态、物流单号、直播金额等关键字段比对，只上传新增或变化的记录
- 批量写入：500 条/批分片上传、5 秒间隔，支持全量重传，降低 WPS 写入压力
- 买家昵称补全：自动打开飞鸽 IM 会话页提取买家昵称，写回买家 ID 映射表
- 诊断完善：全链路日志写入本地存储，可复制、可导出诊断包，敏感字段自动脱敏
- 免登录免逆向：直接复用已登录会话，不破解风控签名参数，规避合规与技术风险
技术与工具
- 形态：Chrome/Edge Manifest V3 扩展，Side Panel 侧边栏交互
- 数据获取：注入 page-bridge.js 拦截 XHR，捕获真实接口模板后直接重放，不操作 DOM
- 通信机制：runtime/tabs 消息、window.postMessage、CustomEvent、declarativeNetRequest 请求头处理、fetch 直传 Webhook 等多通道协作
- 存储：chrome.storage.local 与 IndexedDB 持久化配置、日志与快照
- 同步目标：WPS AirScript Webhook
- 开发方式：AI 编程类工具，结合 browser 与 WPS 多维表格 Skill；国际顶级模型辅助
适用场景
- 单人/小团队运营的抖店商家：无需服务器部署，把订单、售后、直播数据自动归集到 WPS 多维表格做存储分析
- 其他电商平台商家：可参照该思路开发对应插件，把店铺数据自动同步到在线表格，替代手动统计
原始提交内容（点开查看，可复制全文去问 AI）
项目概述 一个 Chrome MV3 浏览器扩展,自动从抖店后台抓取 订单、售后、直播概览 三类数据,通过 WPS AirScript Webhook 同步到 WPS 多维表格,并提供本地差异比对、自动定时采集、诊断日志等能力。
- 功能清单 模块 功能 数据采集 订单/售后/直播概览三类任务;支持“最近 N 天”和“指定日期区间”两种模式 采集触发 自动定时采集(可配时段,如 0-3,8-24);手动一键采集;自动打开/复用目标页并等待就绪 数据获取方式 通过注入 page-bridge.js 拦截 XHR,捕获真实接口模板后直接重放接口(不操作 DOM) 本地缓存 用 IndexedDB 保存上次上传快照,按关键字段(售后状态/订单状态/物流单号/直播金额等)做差异比对,只上传新增或变化记录 上传同步 调用 WPS AirScript Webhook,500 条/批分片上传,5 秒间隔;支持全量重传 买家昵称补全 打开飞鸽 IM 会话页,提取买家昵称写回“买家 ID 映射表” 界面 Side Panel 侧边栏(点击图标切换),展示任务状态、最近结果、诊断日志 诊断 全链路日志写入 chrome.storage.local,可导出诊断包,敏感字段自动脱敏
- 通信机制 项目使用了 6 种通信通道,这是浏览器扩展方案的核心特色:
chrome.runtime.sendMessage — content background 双向消息(下发采集指令、回传上传结果),见 service-worker.js#L160 chrome.tabs.sendMessage — background 主动向指定标签页 content 下发指令 window.postMessage — content 与注入页面的 page-bridge 通信,桥接页面真实 fetch/XHR,见 content.js#L159 CustomEvent — content 向 page-bridge 派发 douyin-refund-sync:api-request 触发接口重放 declarativeNetRequest — 修改发往 kdocs.cn 的请求 origin/referer 头,绕过 WPS Webhook 的来源校验,见 service-worker.js#L346 document attribute — 在 <html> 上写 data-ai-extension-* 属性,供外部测试/探测扩展状态 fetch — 直接 POST 到 WPS AirScript Webhook,带 AirScript-Token chrome.storage.local / IndexedDB — 配置、日志、快照持久化 3. 优势 免登录:直接复用用户已登录的抖店会话 cookie,不需要管理账号密码 免逆向风控:不破解 a_bogus/msToken 等签名,而是通过 page-bridge 拿到页面真实请求模板直接重放(见 content.js#L1160 主动剔除这些参数) 增量同步:本地 IndexedDB 快照比对,只上传有变化的记录,显著降低 WPS 写入压力 批量化:500 条/批自动分片,避免单次请求过大 健壮性:页面未就绪自动打开/刷新、自动采集与手动互斥、停止请求在非中断阶段生效、诊断日志全程留痕 部署门槛低:加载未打包扩展即可,无需服务器 4. 浏览器插件 vs 独立工具 的本质差异 维度 浏览器插件(本项目) 独立工具(脚本/RPA/Selenium/服务端) 登录态 天然继承浏览器 cookie 需自行维护 cookie/扫码登录 风控签名 直接复用页面真实请求,无需逆向 必须逆向 a_bogus 等,或用 Playwright 模拟 跨域限制 用 declarativeNetRequest 改请求头,合法绕过 CORS/防盗链 需自行构造完整 headers UI 集成 Side Panel 原生嵌入浏览器 需独立 GUI 或 Web 生命周期 受浏览器/SW 休眠约束 进程级,可控 多店铺/多机扩展 难(每台机器各自登录) 容易集中部署 无人值守 需保持浏览器开启+登录 可服务器 7×24 维护成本 抖店改版/接口变动易失效 同样依赖接口,但更易灰度 一句话:插件方案把“登录+签名+CORS”三座大山交给浏览器自身解决,换来的是部署简单但难以规模化。
- 优劣势总结 优势
开发与部署成本最低,适合个人/小团队快速上线 规避了抖店风控逆向的合规与技术风险 本地差异同步 + 分片上传,对 WPS 表格友好 诊断日志完善,出问题易定位 劣势
依赖人工环境:浏览器必须开着、抖店必须登录、目标页可能要打开 MV3 Service Worker 会休眠:长任务/自动采集可能被中断(代码中已做恢复处理,但不彻底) 强耦合抖店 DOM/接口结构:fxg.jinritemai.com、compass.jinritemai.com 一旦改版,selectors 与 API path 全部要改 难以多店规模化:每台机器/每个浏览器各自一套,无中心调度 凭据硬编码:DEFAULT_SETTINGS 里的 webhook URL 和 token 写死在 service-worker.js#L53-65,分发时有泄露风险 无法脱离 WPS:目标存储强绑定 WPS AirScript,迁移成本高 6. 在你的场景下是否最优解? 你的场景关键词:盲盒直播电商 + 单人操作 + 数据落 WPS 多维表格 + 抖店后台。
结论:是当前阶段的最优解,但不是长期最优解。
判定依据:
适合用插件的方面
单店/单人操作,不需要多机调度 目标存储就是 WPS 表格,Webhook 直连最短路径 抖店有 a_bogus 风控,逆向既不合规也易失效,插件“借壳重放”是成本最低的合规擦边方案 你已经基于浏览器插件 Skill 跑通了全流程,沉没成本低 ️ 未来需要重新评估的信号
店铺数 3 个,或需要多人共享数据 建议迁移到“服务端 + Playwright 无头浏览器”方案 需要 7×24 无人值守且浏览器经常被关 考虑独立服务 数据量持续增大,WPS 表格写入频繁限流 引入中间数据库(如 SQLite/MySQL)做缓冲 凭据需要安全分发 抽离到配置文件或服务端下发 短期建议(不改变架构):
把 DEFAULT_SETTINGS 里的 token/webhook 抽到独立 config.json,首次启动让用户填入 给 Side Panel 加“心跳检测”,SW 休眠后自动恢复自动采集调度 抖店接口路径/选择器集中到一份 targets.js 常量文件,改版时只改一处 如需要,我可以帮你把第 1 条或第 3 条直接落实成代码改动。