做抖音采集这个方向的博主或数据分析师基本都经历过同样的心路历程一开始以为拿个requests库随便请求一下就能把数据拿下来结果真上手才发现抖音的主页数据接口跟普通网站完全不是一个物种。那些点赞、收藏、分享的数值背后是一整套加密签名、Cookie风控和参数校验机制。这篇就把我自己搭抖音用户主页视频数据采集工具的完整过程拆开讲清楚包括接口定位、参数构造、数据解析、无水印视频下载以及爬取过程中踩过的坑和最终的合规使用思路。1. 抖音用户主页数据采集的第一步先搞清楚目标URL和页面结构1.1 用户主页的三种URL形态与对应关系抖音用户主页存在三种常见的URL表达方式很多人第一步就栽在URL形态混用上。第一种是带有用户数字ID的纯数字链接形如https://www.douyin.com/user/123456789这里的数字其实是抖音内部的用户UID属于较早时期的格式现在已经很少直接暴露在页面上。第二种是带有sec_uid参数的链接这是目前Web端最通用的形态形如https://www.douyin.com/user/MS4wLjABAAAA...sec_uid是一串经过编码的字符串是抖音Web端所有用户主页接口的核心凭证。第三种是用户自定义的抖音号如xxx001这类短链接通常需要通过分享页跳转解析才能拿到真正的sec_uid。搞清楚三种URL的关系之后采集的第一步并不是写爬虫代码而是先确认你手头有哪个参数。因为后续主页视频列表接口、用户信息接口接收的都是sec_uid不是数字UID也不是自定义抖音号。如果只有自定义抖音号就需要先通过https://www.douyin.com/user/自定义抖音号这种页面进去让浏览器完成跳转解析再从最终URL里截取sec_uid。这一步看起来多余实则是后续所有请求的地基。1.2 用浏览器开发者工具锁定视频列表接口打开抖音用户主页按F12进入浏览器的开发者工具切换到Network面板刷新页面就能看到页面发出的所有网络请求。这里有一个很实用的筛选技巧在Network面板的过滤框中输入aweme/v1/web因为抖音Web端的主数据接口都统一走/aweme/v1/web/这个API前缀。比如用户发布的视频列表接口就是/aweme/v1/web/aweme/post/用户基础信息接口是/aweme/v1/web/user/profile/other/。实际抓包时你会看到每往下滚动一屏列表就会重新触发一次aweme/post请求每个请求会带着不同的max_cursor参数返回新的视频数据。这个max_cursor本质上是分页游标接口返回的JSON里有一个max_cursor字段给到下一次请求的Query参数里即可翻页而不是传统意义的页码数字。我第一次实现翻页时下意识用了第1页、第2页的思路结果发现请求返回的数据一直不变后来才意识到游标分页的核心逻辑是把上一次响应的max_cursor原样传回下一次。1.3 接口关键参数说明把aweme/post接口的请求参数挨个拆开看就会发现真正起作用的参数其实集中在几个字段里。device_platform、aid、channel这三个属于环境标识直接用固定值webapp、6383、channel_pc_web即可。pc_client_type和version_code是客户端类型与版本号保持稳定对降低风控概率有帮助。最关键的参数是sec_user_id它的值就是主页URL里的那串字符串拼接位置在Query里。count参数控制单次返回条数默认是18最大可以开到24超过这个数抖音后端会强制拉回默认值。max_cursor负责游标分页首次请求填0之后从响应里拿。locate_query为false时不做定位过滤publish_video_strategy_type需要填2这个参数决定接口返回的是按时间倒序的发布视频如果缺失或填错接口有时候会混入推荐流数据。a_bogus是签名参数由前端JavaScript动态计算的加密字符串长度通常在512字节左右后续章节详细讲它的过期机制。还有cookie中的ttwid和msToken其中msToken可以通过请求前置的token接口拿到也可以自己构造合法字符串关键是这个值不能为空。2. 数据采集的关键前提签名参数与Cookie风控的实际工作机制2.1 签名参数a_bogus的作用与生成原理抖音Web端绝大多数数据接口都要求带a_bogus签名参数这个参数的实际用途是服务端用来校验请求的合法性防止非浏览器环境直接调用接口。它的生成逻辑大概是把当前请求的URL路径、Query参数、Cookie片段、浏览器环境指纹canvas、UA、时间戳等组合起来经过一套混淆的JS算法计算得到。这套算法整体对外是一个压缩混淆过的JavaScript文件通常通过页面加载的webmssdk.js脚本暴露出来。如果跳过签名直接请求接口抖音后端会在几秒钟内返回status_code为0的业务响应虽然HTTP状态码是200但aweme_list字段是空的data里只带一个空列表。很多新手在这里会误以为IP被屏蔽了其实只是签名缺失或过期导致的参数校验失败。2.2 签名过期和Cookie失效的两种典型场景我实际使用中总结出两个高发场景需要特别留意。第一个是签名与请求参数不匹配导致的即时失效比如先构造好URL等待几秒后重新改了max_cursor但a_bogus还是之前计算的那串这时服务端拿签名去校验URL时发现参数对不上直接返回空数据。解决办法是每修改一次请求参数就重新生成一次签名绝不能复用旧签名。第二个是msToken过期msToken是服务端下发的会话令牌有效期通常在一小时到一天之间。只要页面不关闭浏览器会定期刷新它。但用脚本请求时如果长时间不更新msToken会触发风控校验表现是首页接口正常但二次翻页后突然开始返回验证码页。实际风控告诉我们最稳妥的方案是让浏览器先正常操作几分钟再把浏览器开发者工具里的请求头全套复制到脚本中不要手动精简Cookie字段。2.3 降低风控触发的请求频率设计请求频率是整个采集工程里最需要拿捏的部分。请求太慢数据到手黄花菜都凉了请求太快账号和IP双双被风控。经过多轮测试我的经验是aweme/post这类主页数据接口宜控制在每3到5秒请求一次每采完一个用户主页最好停上10秒以上再切换下一个用户。如果目标用户视频数量超过两三百条建议分段采集每采半个小时后休息两分钟。短时间内对同一个用户主页连续发几十次请求触发概率会直线上升表现是接口返回正常的status_code但data里出现captcha等字段整个会话需要重新验证才能恢复。3. 主页视频数据解析点赞、收藏、分享、评论等互动指标的位置与口径3.1 视频列表接口的响应结构一次成功的aweme/post请求会返回一个比较大的JSON对象核心内容落在aweme_list数组里。这个数组的每个元素代表一条视频的完整详情包含视频ID、描述文本、创建时间、时长、宽高比、音乐信息、话题标签等字段。aweme_list数组后面跟着两个用于分页的字段max_cursor表示下一次请求的游标值has_more为1则说明还有更多数据为0则表示已到末尾。兄弟接口aweme/v1/web/aweme/detail/可以按视频ID查询单条视频的详情它接收aweme_id参数返回结构与列表接口基本一致适合做增量更新或修复列表接口漏掉的数据。3.2 statistics字段里的互动数据明细每条视频的statistics子对象就是本项目的核心收货区。digg_count表示点赞数comment_count表示评论数collect_count表示收藏数share_count表示分享数play_count表示播放量。这里有个需要注意的口径细节play_count字段在Web端的部分视频里有可能是0或缺失这是因为播放量属于高实时性变更指标服务端会对未达到一定规模的视频隐藏播放量。点赞、评论、收藏、分享四个指标则是基本都能正常返回的。除了statistics之外aweme_list里的video子对象也值得重点关注。video下有一个play_addr对象里面包含了视频的播放地址列表url_list通常第一个是最高清版本。还有width、height这两个字段标注了分辨率duration字段的单位是毫秒换算成秒需要除以1000。如果这个视频本身有封面图那video.cover.url_list里就是封面图的URL。这些字段对做数据分析、做内容库、做视频封面归档都非常有用但和statistics不一样的是它们不是采集的必选项按需提取就好。3.3 其他高价值字段描述、话题、音乐与定位互动数据只是视频数据的骨架要让后续的数据分析更有价值还需要把视频本身的属性字段一并采集下来。desc字段是视频的文字描述也就是视频文案text_extra数组里每一条数据记录视频描述中出现的#话题标签和用户其中hashtag_name就是话题名称user_id是用户的IDsec_uid是用户的加密IDmusic对象里有音乐标题title、作者author和时长durationgeolocation字段会返回视频的定位信息但很多视频没有开启定位这个字段经常是空对象。把这些视频的文案、话题、音乐、定位信息连同点赞、收藏、分享、评论数据一并存储进数据库后续做内容趋势分析、用户画像分析、爆款预测建模时都有直接用得上的数据基础。我自己的数据表里通常把这些字段全部铺开建立独立的列方便后续做SQL聚合查询。4. 视频文件下载无水印视频地址的解析方案与文件名规划4.1 替换playwm参数实现无水印地址解析视频文件下载是很多人的刚需尤其做素材整理或爆款拆解时需要把视频原文件下载到本地。抖音Web端接口返回的play_addr.url_list地址直接下载下来会发现个别视频带有半屏水印这个水印实际上来自地址中的playwm参数。一个高效且稳定的做法是在拿到播放地址后把URL中的playwm字符串替换成play再请求一次即可得到无水印版本。这套替换方法几乎适用于Web端所有视频接口包括aweme/post列表里的视频和aweme/detail单条详情里的视频。不过实测有一部分视频的url_list地址中并没有playwm字段那说明这条视频本身就没有水印直接下载即可。替换前先判断一下URL中是否包含playwm可以避免无意义的字符串替换操作也让代码更健壮。4.2 下载流程与请求头注意事项视频下载流程并不复杂从aweme_list的video.play_addr.url_list里取出播放地址替换playwm为play然后发起GET请求将返回的二进制内容写入本地文件。但这里有一个细节容易被忽略视频CDN对Referer和User-Agent较真的程度比接口高。直接在浏览器地址栏打开视频地址时能正常播放放到脚本里不带Referer去下载偶尔会命中403所以下载时需要带上Referer: https://www.douyin.com/和浏览器UA。下载文件的后缀名直接从播放地址里判断通常.mp4但也有一些是.m3u8切片形式后者属于HLS流媒体不能简单当普通文件落盘后续要单独处理。命名规划上我习惯用视频ID_点赞数_收藏数_分享数.mp4的格式这样下载下来的文件在文件管理器里就自带互动数据预览做素材筛选时根本不用再打开数据库。4.3 批量下载与进度管理批量下载的关键是控制并发数和做已下载记录。多个视频同时下载虽然能提升速度但抖音CDN也有连接数限制并发开太大会出现部分连接被重置或者速度很不稳定。我一般用线程池把并发控制在3到5个每个线程下载完一个视频后立即释放资源。已下载记录我建议直接维护一张本地表记录视频ID和文件路径下次跑批时先查表跳过已下载的视频。这样可以防止任务中断后重新跑一遍造成重复下载也能在视频被删除或接口变更后帮你快速定位哪些文件是从旧接口下载的。文件落盘时采用临时文件加改名的策略也能防止下载一半的文件残留在目标目录。5. 高频踩坑记录从空列表返回到数据字段错位的完整排查链路5.1 场景一接口返回200但aweme_list为空数组这是我被问得最多的一个问题也是整个采集过程中最坑的场景。接口HTTP状态码是200JSON响应里的status_code也是0但aweme_list就是一个空数组has_more直接变成0。第一次遇到时我怀疑是目标用户设置了隐私保护后来换了几个公开大V账号测试还是一样才意识到问题出在请求本身。参照前面讲过的签名机制逐项排查后的完整链路是第一步检查a_bogus是否为最新值因为只要修改过任何Query参数就必须重新生成签名第二步检查msToken是否过期换一个新的试试第三步检查Cookie里的ttwid是否还在有效期内这个字段有时候会单独失效第四步把浏览器里能看到的所有请求头原样复制到脚本里尤其是sec-fetch-site、sec-fetch-mode、sec-fetch-dest这三个字段缺失它们会让服务端判定请求来自非浏览器。这套链路排查下来绝大多数空列表问题都能解决。5.2 场景二翻页时数据一直重复翻页数据重复的根源几乎都是max_cursor使用错误。很多教程里会把max_cursor和cursor混用实际上aweme/post接口第一次请求携带的max_cursor为0后续必须用上一次响应体的max_cursor字段值。如果错误地使用了cursor字段抖音后端会把请求视为从第一页重新开始导致返回的数据永远是最开始那批。正确的翻页循环应该这样设计初始化max_cursor 0请求后取出响应里的max_cursor赋值给下一次请求直到has_more等于0或连续多次返回的max_cursor不变循环结束。这里的防死循环别忽略因为个别用户视频数量较少时has_more可能直接返回0但有些账号在服务端异常的情况下会一直返回has_more1和相同的max_cursor不做防护就会无限循环下去。5.3 场景三视频描述中的emoji导致存储报错视频文案里包含大量emoji和特殊符号这是博主文案区最常见的特征。如果数据库表结构用的是utf8字符集而非utf8mb4写入含emoji的数据时会直接报Incorrect string value错误导致整条视频记录无法入库。解决方法是把表字符集和连接字符集都改为utf8mb4。如果你用的是MySQL建表时加上DEFAULT CHARSETutf8mb4即可。如果你用SQLite基本没有这种编码障碍但要注意Python环境的ensure_ascii设置。JSON序列化时Python默认还是会编码非ASCII字符的因此写入文件时建议设置ensure_asciiFalse这样保存下来的JSON文件里才是剩余人类可读的中文文案而不全是转义序列。5.4 场景四部分视频拿不到完整statistics字段有个别视频的statistics字段里只有digg_count和comment_countcollect_count和share_count缺失。这通常发生在刚发布不久的新视频上服务端尚未完全聚合出四项指标。处理上不要直接取statistics.get(collect_count)然后塞进数据库否则会写入空值影响后续统计。稳妥的处理是给这四个字段都设置默认值0用类似int(data.get(statistics, {}).get(collect_count) or 0)的方式取值。再进一步就做增量覆盖更新第一次采集到缺失数据过一两天重新采集时把已有记录更新成完整值。做数据仓库的同学应该对这个模式很熟悉本质上就是拉链表的思路。6. 数据处理与落库从接口返回的JSON到结构化数据表6.1 数据表字段设计与存储建议数据采集完成后数据结构化是决定后续分析顺手程度的关键步骤。我给主页视频数据设计的数据表包含以下核心字段aweme_id视频ID主键、desc视频描述、create_time发布时间戳、duration时长毫秒、digg_count点赞数、comment_count评论数、collect_count收藏数、share_count分享数、play_count播放数、video_url无水印视频地址、cover_url封面地址、hashtags话题标签列表JSON格式、music_title背景音乐名、author_sec_uid作者加密ID等。我的习惯是明细数据全量落到一张明细表支付宝的每个字段都单独建列方便后期做Group By聚合查询话题标签和音乐信息存在独立表或字段里用JSON存储虽然违反数据库范式但胜在灵活爬虫数据每天结构都有可能微调与其频繁改表结构不如JSON兜底。查询时用JSON_EXTRACT也能提取出需要的内容。6.2 数据更新策略与增量采集视频的互动数据是实时变化的昨天点赞10万的作品今天可能已经涨到30万。如果只采集一次数据很快就会失真。我的增量策略是首次全量采集后每隔6到12小时对目标用户做一次增量采集采集时只保留aweme_id和最新的statistics字段对已存在的记录做更新操作。增量更新的SQL可以写成INSERT ... ON DUPLICATE KEY UPDATE这样既能插入新视频又能更新老视频的互动数据一步到位。时间上注意避开流量高峰时段比如晚上8点到11点用户的活跃度极高服务端风控算法也更敏感我一般选择凌晨或清晨做增量任务。7. 合规边界与数据使用方式的务实建议抖音用户主页视频数据采集这个方向技术本身是中性的但使用方式必须放在法律法规和平台规则的框架内。无论是出于学习研究、数据分析还是个人素材整理的需要都要明确几条底线第一采集范围应限于公开且无需登录即可访问的数据不对私密账号、好友可见内容进行越权抓取第二采集频率必须克制不给目标服务器制造过大压力这也是工程上必须遵守的礼貌第三采集到的数据禁止用于任何商业牟利或损害他人合法权益的场景尤其是不能批量搬运他人作品去第三方平台发布。从个人经验来说这个项目最适合的应用场景是自媒体运营者分析对标账号的内容策略、数据分析师研究短视频平台的创作趋势、算法工程师构建视频推荐模型时做特征工程的数据准备。这些用途都建立在公开数据基础上且最终产出物是分析结论、统计图表或改进后的模型而不是对原始内容的二次传播。务必把合规意识植入到自动化任务的每一个环节里这才是做一个长期稳定的采集工程系统的前提。另外提一个很多人容易忽略的合规细节视频下载后的本地文件也属于他人作品的复制件即使不商用在公开场合展示或共享也需要谨慎最好只保留在个人可控制的环境中。把这个边界想清楚后续的技术迭代才能走得踏实。