做抖音采集这个方向的博主或数据分析师，基本都经历过同样的心路历程：一开始以为拿个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是@用户的ID，sec_uid是@用户的加密ID；music对象里有音乐标题title、作者author和时长duration；geolocation字段会返回视频的定位信息，但很多视频没有开启定位，这个字段经常是空对象。
把这些视频的文案、话题、音乐、定位信息连同点赞、收藏、分享、评论数据一并存储进数据库，后续做内容趋势分析、用户画像分析、爆款预测建模时都有直接用得上的数据基础。我自己的数据表里通常把这些字段全部铺开建立独立的列，方便后续做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状态码是200，JSON响应里的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_more=1和相同的max_cursor，不做防护就会无限循环下去。
5.3 场景三：视频描述中的emoji导致存储报错
视频文案里包含大量emoji和特殊符号，这是博主文案区最常见的特征。如果数据库表结构用的是utf8字符集而非utf8mb4，写入含emoji的数据时会直接报Incorrect string value错误，导致整条视频记录无法入库。解决方法是把表字符集和连接字符集都改为utf8mb4。
如果你用的是MySQL，建表时加上DEFAULT CHARSET=utf8mb4即可。如果你用SQLite，基本没有这种编码障碍，但要注意Python环境的ensure_ascii设置。JSON序列化时Python默认还是会编码非ASCII字符的，因此写入文件时建议设置ensure_ascii=False，这样保存下来的JSON文件里才是剩余人类可读的中文文案，而不全是转义序列。
5.4 场景四：部分视频拿不到完整statistics字段
有个别视频的statistics字段里只有digg_count和comment_count，collect_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. 合规边界与数据使用方式的务实建议
抖音用户主页视频数据采集这个方向，技术本身是中性的，但使用方式必须放在法律法规和平台规则的框架内。无论是出于学习研究、数据分析还是个人素材整理的需要，都要明确几条底线：第一，采集范围应限于公开且无需登录即可访问的数据，不对私密账号、好友可见内容进行越权抓取；第二，采集频率必须克制，不给目标服务器制造过大压力，这也是工程上必须遵守的礼貌；第三，采集到的数据禁止用于任何商业牟利或损害他人合法权益的场景，尤其是不能批量搬运他人作品去第三方平台发布。
从个人经验来说，这个项目最适合的应用场景是自媒体运营者分析对标账号的内容策略、数据分析师研究短视频平台的创作趋势、算法工程师构建视频推荐模型时做特征工程的数据准备。这些用途都建立在公开数据基础上，且最终产出物是分析结论、统计图表或改进后的模型，而不是对原始内容的二次传播。务必把合规意识植入到自动化任务的每一个环节里，这才是做一个长期稳定的采集工程系统的前提。
另外提一个很多人容易忽略的合规细节：视频下载后的本地文件也属于他人作品的复制件，即使不商用，在公开场合展示或共享也需要谨慎，最好只保留在个人可控制的环境中。把这个边界想清楚，后续的技术迭代才能走得踏实。
