简介DouYin_Spider 是一套面向移动应用爬虫学习者的抖音数据抓取实践项目适合具备 Python 基础、希望理解 Appium 自动化、Mitmproxy 流量拦截与 Genymotion 模拟器协同工作的开发者。项目通过模拟真实用户操作与中间人代理分析解决移动端数据非公开、接口加密等抓取难点并涉及抓取策略设计、反爬规避及 JSON 数据解析存储等环节。资源包共 3 个文件包含 2 个 Python 脚本与 1 个 Markdown 说明文档压缩后约 4KB脚本分别承担下载调度与自动化控制职责文档用于梳理项目结构与使用思路。目前已有 457 人学习读者可借此掌握移动应用爬虫从环境搭建、流量捕获到数据落库的完整链路积累自动化测试与竞争情报采集的实战经验。1. 短视频公开数据采集DouYin_Spider 到底在采什么、采来做什么很多人第一次听到 DouYin_Spider 这个名字脑子里蹦出来的是“爬虫”两个字然后立刻想到封号、限流、法律风险。但真正在业务里用过这类工具的人知道它解决的其实是一个非常具体的工程问题把短视频平台上公开可见的视频元数据、评论、话题标签、创作者主页信息按关键词或账号维度批量拉下来落成结构化表格供后续做选题分析、竞品监测、舆情归因或者推荐算法训练。它不碰私密内容不绕登录态核心难点在于请求签名、频控节奏和字段解析的稳定性。适合谁用做内容运营的数据分析同学、做推荐系统需要冷启动语料的算法工程师、以及做品牌监测的产品经理。如果你只是想手动看几条视频那没必要上这套东西但当你需要每天跟踪几百个关键词、几千条评论的时候手工复制粘贴就是纯体力活DouYin_Spider 这类方案的价值才真正体现出来。2. 请求链路拆解从关键词到结构化字段要过哪几道关2.1 公开数据采集的合法边界与字段范围先把边界说清楚这是所有后续工作的前提。DouYin_Spider 这类工具采集的对象严格限定在无需登录即可访问的公开页面和公开接口返回的数据。具体来说能拿到的字段包括视频标题、发布时间、点赞数、评论数、分享数、收藏数、视频时长、封面图地址、作者昵称、作者公开主页的粉丝数和作品数、话题标签、音乐名称、以及公开评论区的前若干页评论内容。拿不到的、也不应该去尝试的是私密账号内容、私信、手机号、精确地理位置、以及需要登录态才能看到的个人设置信息。提示任何采集行为都要先确认目标平台的服务条款和当地数据保护法规公开数据不等于可以随意批量抓取和二次分发。从工程角度看字段范围决定了请求链路的设计。比如你只要视频维度的聚合数据那走搜索接口就够了如果要评论就得额外处理评论分页和二级评论的展开逻辑。我一般会先把需求拆成“视频列表”和“评论列表”两张目标表再倒推需要调哪些接口。2.2 签名参数与请求头的构造逻辑这是整个链路里最容易翻车的一环。短视频平台的公开接口通常带有一组动态签名参数常见的是X-Bogus、_signature这类字段它们由前端 JS 根据请求参数、时间戳、设备信息等混合计算得出。DouYin_Spider 的常见做法是把签名算法从 JS 里逆向出来用 Python 或 Node.js 复现每次请求前动态生成。下面是一个简化的签名参数构造示例用 Python 演示思路import time import hashlib import urllib.parse def build_common_params(device_id: str, aid: str 6383) - dict: 构造公开接口的通用查询参数。 device_id: 设备标识通常随机生成后固定复用 aid: 应用标识公开接口常见固定值 ts int(time.time()) params { device_platform: web, aid: aid, channel: channel_pc_web, pc_client_type: 1, version_code: 170400, version_name: 17.4.0, cookie_enabled: true, screen_width: 1920, screen_height: 1080, browser_language: zh-CN, browser_platform: Win32, browser_name: Chrome, browser_version: 120.0.0.0, os_name: Windows, os_version: 10, device_id: device_id, ts: str(ts), } return params def sign_params(params: dict, salt: str your_salt_here) - str: 对参数排序后拼接盐值做哈希模拟签名生成。 实际签名算法更复杂这里只展示参数排序和拼接逻辑。 sorted_items sorted(params.items()) raw urllib.parse.urlencode(sorted_items) salt return hashlib.md5(raw.encode()).hexdigest()这段代码的逻辑说明build_common_params负责拼装每次请求都需要的公共参数其中device_id是关键建议生成一次后持久化复用频繁更换反而容易触发风控。sign_params展示了签名计算的基本套路——参数按 key 排序、urlencode、拼接盐值、哈希。实际项目中签名算法往往涉及多层混淆需要配合浏览器调试工具逐层还原。参数说明aid和version_code这类字段会随平台前端版本更新而变化不是永久固定的。我一般会把这些易变参数抽到配置文件里方便后续替换而不是硬编码在业务逻辑中。2.3 分页游标与频控节奏的配合拿到签名之后下一个问题是分页。公开搜索接口通常用offsetcount或者cursorhas_more的方式翻页。DouYin_Spider 的常见实现是维护一个游标状态机每次请求返回has_more为 true 时把返回体里的cursor值存下来作为下一页的入参。频控方面血泪经验是不要贪快。我一般会设置每请求间隔 1.5 到 3 秒的随机延迟单账号单 IP 每分钟不超过 20 次请求。如果要做大批量采集更稳妥的做法是分时段跑比如每小时跑一批每批控制在 200 次请求以内。下面是一个带频控的请求循环骨架import time import random import requests def fetch_with_throttle(url: str, params: dict, headers: dict, max_retries: int 3) - dict: 带频控和重试的请求封装。 max_retries: 遇到 429 或 5xx 时的最大重试次数 for attempt in range(max_retries): try: # 随机延迟模拟人工浏览节奏 time.sleep(random.uniform(1.5, 3.0)) resp requests.get(url, paramsparams, headersheaders, timeout10) if resp.status_code 200: return resp.json() elif resp.status_code 429: # 被限流退避时间加倍 time.sleep(5 * (attempt 1)) else: time.sleep(2) except requests.RequestException: time.sleep(3) return {} def crawl_by_cursor(base_url: str, base_params: dict, headers: dict, max_pages: int 50) - list: 按游标翻页采集直到 has_more 为 false 或达到 max_pages。 results [] cursor 0 for _ in range(max_pages): params {**base_params, cursor: cursor, count: 20} data fetch_with_throttle(base_url, params, headers) items data.get(data, {}).get(list, []) if not items: break results.extend(items) if not data.get(data, {}).get(has_more): break cursor data.get(data, {}).get(cursor, 0) return results逻辑说明fetch_with_throttle把延迟、重试、退避策略封装在一起业务层不用关心这些细节。crawl_by_cursor负责游标推进max_pages是硬性上限防止因为接口异常导致无限循环。参数count一般设 20设太大容易触发风控设太小则请求次数翻倍。3. 字段解析与落库把嵌套 JSON 拍平成能分析的表格3.1 视频与评论的嵌套结构拆解公开接口返回的 JSON 通常是多层嵌套的。以视频搜索为例一条记录里可能包含aweme_info、author、statistics、video等子对象评论则藏在comments数组里每条评论还有reply_comment二级结构。直接存原始 JSON 不是不行但后续做 SQL 分析会很痛苦。我一般会写一层拍平函数把需要的字段提取成扁平字典。def flatten_video(item: dict) - dict: 从搜索结果的单条记录中提取视频维度字段。 aweme item.get(aweme_info, {}) author aweme.get(author, {}) stats aweme.get(statistics, {}) video aweme.get(video, {}) return { aweme_id: aweme.get(aweme_id, ), desc: aweme.get(desc, ).replace(\n, ), create_time: aweme.get(create_time, 0), author_uid: author.get(uid, ), author_nickname: author.get(nickname, ), author_follower_count: author.get(follower_count, 0), digg_count: stats.get(digg_count, 0), comment_count: stats.get(comment_count, 0), share_count: stats.get(share_count, 0), collect_count: stats.get(collect_count, 0), duration: video.get(duration, 0), cover_url: (video.get(cover, {}).get(url_list) or [])[0], } def flatten_comment(comment: dict, aweme_id: str) - dict: 提取评论维度字段并带上所属视频 ID 作为外键。 user comment.get(user, {}) return { comment_id: comment.get(cid, ), aweme_id: aweme_id, text: comment.get(text, ).replace(\n, ), digg_count: comment.get(digg_count, 0), create_time: comment.get(create_time, 0), user_uid: user.get(uid, ), user_nickname: user.get(nickname, ), reply_count: comment.get(reply_comment_total, 0), }逻辑说明拍平函数的核心原则是“只取需要的字段缺失给默认值”。aweme_id和comment_id是后续做去重和关联的关键主键必须保留。文本字段里的换行符建议在入库前替换掉否则导出 CSV 时容易串行。参数说明create_time是 Unix 时间戳落库后建议转成 datetime 类型方便按天聚合。duration单位是毫秒做时长分析时记得除以 1000。3.2 用 SQLite 做本地落库与去重小规模采集用 SQLite 就够了零配置、单文件、支持 SQL 查询。建表时把aweme_id设为主键配合INSERT OR IGNORE实现天然去重。import sqlite3 def init_db(db_path: str douyin_spider.db) - sqlite3.Connection: conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS videos ( aweme_id TEXT PRIMARY KEY, desc TEXT, create_time INTEGER, author_uid TEXT, author_nickname TEXT, author_follower_count INTEGER, digg_count INTEGER, comment_count INTEGER, share_count INTEGER, collect_count INTEGER, duration INTEGER, cover_url TEXT ) ) conn.execute( CREATE TABLE IF NOT EXISTS comments ( comment_id TEXT PRIMARY KEY, aweme_id TEXT, text TEXT, digg_count INTEGER, create_time INTEGER, user_uid TEXT, user_nickname TEXT, reply_count INTEGER ) ) conn.commit() return conn def save_videos(conn: sqlite3.Connection, rows: list): conn.executemany( INSERT OR IGNORE INTO videos VALUES ( :aweme_id, :desc, :create_time, :author_uid, :author_nickname, :author_follower_count, :digg_count, :comment_count, :share_count, :collect_count, :duration, :cover_url ) , rows) conn.commit()逻辑说明INSERT OR IGNORE保证重复采集同一批数据时不会报错也不会产生重复行。executemany批量写入比逐条插入快一个数量级。参数db_path建议按采集日期分文件比如douyin_20250101.db方便回溯和清理。3.3 导出 CSV 与快速校验落库之后导出 CSV 给非技术同学用是常见需求。同时建议加一个简单的校验步骤检查关键字段的空值率。import csv import sqlite3 def export_videos_to_csv(conn: sqlite3.Connection, csv_path: str): cursor conn.execute(SELECT * FROM videos ORDER BY create_time DESC) columns [d[0] for d in cursor.description] with open(csv_path, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow(columns) writer.writerows(cursor.fetchall()) def check_null_rate(conn: sqlite3.Connection, table: str, column: str) - float: total conn.execute(fSELECT COUNT(*) FROM {table}).fetchone()[0] if total 0: return 0.0 nulls conn.execute( fSELECT COUNT(*) FROM {table} WHERE {column} IS NULL OR {column} ).fetchone()[0] return round(nulls / total, 4)逻辑说明导出时用utf-8-sig编码Excel 打开不会乱码。check_null_rate用来快速判断某次采集是否正常比如author_nickname空值率超过 30%大概率是接口返回结构变了需要检查解析逻辑。4. 避坑与排查采集过程中最容易翻车的五个点4.1 签名失效导致全部请求返回空数据现象程序不报错但每次返回的data.list都是空数组或者status_code是 0 但数据为空。原因平台前端更新了签名算法或公共参数旧的签名逻辑算出来的值不被服务端认可。解决先用浏览器开发者工具抓一条真实请求对比自己的参数和签名结果逐字段排查差异。重点检查X-Bogus和_signature是否缺失或格式不对。我一般会在代码里加一个“空数据告警”连续三页返回空就打印当前请求参数方便定位。4.2 频控触发后 IP 被临时限制现象请求开始返回 429 或者直接连接超时换一个接口路径也一样。原因短时间内请求密度过高触发了平台侧的频控策略。解决立即停止当前任务至少等待 30 分钟再试。后续把请求间隔调大到 3 到 5 秒并且单次任务的总请求数控制在 300 以内。如果业务量大考虑分多个时段跑而不是一次性拉满。4.3 评论分页丢数据现象采集到的评论数远少于视频页面上显示的评论总数。原因评论接口通常只返回前若干页且二级评论需要单独请求reply接口。另外部分评论可能因为审核状态不对外展示。解决接受“公开可见评论”和“显示总数”之间的天然差距不要试图绕过。在报告里注明“采集范围为公开可见评论”避免误导。如果需要二级评论单独写一个递归函数处理reply_comment字段。4.4 字段类型不一致导致入库失败现象sqlite3.InterfaceError或者数据写入后查询结果异常。原因接口返回的某些字段类型不稳定比如digg_count有时是整数有时是字符串create_time有时是秒级有时是毫秒级。解决在拍平函数里做强制类型转换用int()包一层并给默认值 0。时间戳统一转成秒级毫秒级的除以 1000。4.5 设备 ID 复用不当引发验证码现象运行一段时间后请求开始返回验证码页面或者要求滑块验证。原因device_id生成过于频繁或者多个任务共用同一个 ID 导致行为异常。解决一个采集任务固定用一个device_id持久化到本地文件不要每次启动都重新生成。如果已经触发验证换一个 ID 并降低请求频率通常几小时后恢复正常。5. 进阶技巧把采集频率和字段扩展做成可配置的走到这里基础链路已经能跑通了。但实际业务里需求是会变的——今天采关键词 A明天要加关键词 B后天又要多采一个“音乐名称”字段。如果每次都改代码维护成本很高。我的习惯是把采集配置抽成一个独立的 JSON 文件把关键词列表、请求间隔、最大页数、目标字段都做成可配置项。import json def load_config(path: str spider_config.json) - dict: 加载采集配置支持热更新。 配置文件示例 { keywords: [关键词A, 关键词B], min_interval: 2.0, max_interval: 4.0, max_pages: 30, enable_comments: true, comment_max_pages: 5 } with open(path, r, encodingutf-8) as f: config json.load(f) # 基础校验防止配置写错导致任务异常 assert config.get(keywords), keywords 不能为空 assert config[min_interval] config[max_interval], 间隔区间不合法 return config逻辑说明配置文件把“采什么”和“怎么采”解耦业务同学改关键词不需要动代码。assert做基础校验避免因为配置笔误导致任务跑飞。参数enable_comments控制是否采集评论关掉可以显著降低请求量。另一个进阶方向是字段扩展。比如你想分析视频的配乐趋势就需要从music对象里提取title和author想分析话题热度就从text_extra里提取hashtag_name。这些扩展字段建议单独建表不要往主表里硬塞否则表结构会越来越臃肿。验证采集质量的一个实用技巧是抽 10 条视频手动打开页面核对点赞数、评论数、发布时间三个字段如果误差在可接受范围内点赞数可能因为实时变化有少量偏差说明解析逻辑是可靠的。我一般会在每次调整解析代码后跑一遍这个核对流程比写单元测试更直接。最后说一个我踩过的坑曾经为了追求“全量”把请求间隔调到 0.5 秒结果跑了不到 200 条就被限流白白浪费了一个下午。后来改成 3 秒间隔、分时段跑反而整体效率更高因为不用处理限流后的等待和重试。慢就是快这句话在公开数据采集里特别成立。希望帮到你。本文还有配套的精品资源点击获取