19 位纯数字和 v 开头的一串字母有什么区别？douyin-vue 视频播放原理全解

19 位纯数字和 v 开头的一串字母有什么区别？douyin-vue 视频播放原理全解

【免费下载链接】douyinVue3 + Pinia 仿抖音，Vue 在移动端的最佳实践 . Imitate TikTok ，Vue Best practices on Mobile项目地址: https://gitcode.com/GitHub_Trending/do/douyin

douyin-vue 是一个用 Vue3 + Pinia 搭建的仿抖音移动端项目，它能让视频像刷抖音一样上下滑动播放，背后靠的其实是两种标识：aweme_id 与 video_id。如果你也疑惑过"手里明明有 ID，为什么查不到数据、播不出视频"，这篇机制拆解会顺着一次播放请求，讲清这两个 ID 的分工和数据的完整流转。

先说困境：为什么拿着 ID 还是查不到、播不了

第一次翻抖音的数据时，很多人都会撞上一堵墙：抓回来的 JSON 里同时躺着7265649807396474112这样一串 19 位数字，和v0300fg10000cna0c8bc77ufge7emlsg这样一串字母数字混合值。拿前者去拼评论接口报空，拿后者去拼播放地址报 403，两边都不通。💡 问题不在数据缺失，而在于把两把不同用途的钥匙用反了。

它们各自管的事，可以列成一张对照表：

打个比方：这像去图书馆借书。书脊上的索书号（比如I247.5/1234）能让你在目录里查到这本书的书名、作者、出版年份，但它不告诉你书摆在哪个书架；真正取书，得靠书架位置贴——几区几排第几层。aweme_id 就是索书号，video_id 就是书架位置贴。拿索书号你找不到书，拿位置贴也查不到书的信息，两者各自回答的问题完全不同：一个回答"这是谁的哪条作品"，另一个回答"文件在 CDN 的哪一层架子上"。

播放地址藏在哪个字段里：拆开 video.play_addr 看

在 public/data/videos.json 里，两条 ID 的藏身位置不一样：aweme_id直接挂在每条记录的顶层，随手可取；而 video_id 并没有独立字段摆在顶层，它埋在video.play_addr这个对象里。把这一层拆开，关键子字段有四个：

1. uri：裸的 video_id 本体，例如v0300fg10000cna0c8bc77ufge7emlsg。注意它只是"门牌"，不能直接当地址用。
2. url_list：一组拼好的完整播放地址，形如https://www.douyin.com/aweme/v1/play/?video_id=...&line=0&file_id=...&sign=...。把 URL 参数摊开看：video_id是门牌，file_id是这份文件独有的指纹，sign是服务端当场签发、带保质期的临时凭证。
3. file_hash：文件内容的哈希值。对照数据会发现，这条记录里sign的值和file_hash恰好一致——签名就是基于文件指纹算出来的，这正好说明"门牌 + 签名"缺一不可。
4. url_key：例如v0300fg10000cna0c8bc77ufge7emlsg_h264_720p_1495002，把 video_id、编码和分辨率串在一起。同一部作品出 720p 和 1080p 两份文件时，就是靠这种 key 区分的——这也是"video_id 跟着文件走"的实证。

这里有个隐藏关系要强调：裸 video_id 单独存在时，只是一张"半张票"，必须配上sign才能从 CDN 换回文件。这就是项目里存的是带 sign 的完整 URL 列表、而不是只存一个 video_id 让你现场拼的原因——签名不是想拼就能拼的，得服务端给。

项目里的两条链路：一条查数，一条放片

查数链路：aweme_id 一路领路

评论数据是这条链路最典型的样本。脚本 node/comment/process.js 里维护了一份 ID 列表，把一次抓回的大评论 JSON 按aweme_id逐条过滤，拆成一个个小文件写进 public/data/comments/。⚠️ 这里有个新手极易绕晕的细节：拆出来的文件名叫video_id_7260749400622894336.json，前缀是video_id_，可文件里每条记录的 key 其实是 aweme_id——命名和字段对不上号，恰恰是"两种 ID"最容易混淆的地方。

前端侧，评论请求走/video/comments，由 src/mock/index.ts 拦截后按 id 参数去读comments/video_id_${id}.md返回，全程没有碰真正的抖音服务器。

播放链路：只回放现成 URL，不实时算地址

前端接口定义集中在 src/api/videos.ts，recommendedVideo、myVideo、videoComments这些函数都只做"发请求、收数据"这一件事。真正扮演后端角色的是 src/mock/index.ts：它用 axios-mock-adapter 拦截这些请求，从本地 JSON 快照里按start/pageSize切片后返回。

数据到了页面，src/components/slide/BaseVideo.vue 直接拿item.video.play_addr.url_list逐个生成<source>标签喂给<video>，浏览器开始播放。整条播放链路上没有任何一步去实时计算地址——项目从头到尾只"回放"抓取时存好的现成 URL。

想自己抓一份数据，两种拿 video_id 的办法

如果你想复刻这套本地数据，video_id 的常见来源有两种，附一个保存思路：

办法一：浏览器抓包。在抖音 PC 网页版打开任意视频，按 F12 打开开发者工具，Network 面板过滤play关键字。视频开始加载的瞬间会出现play/?video_id=...这样的请求，URL 里的video_id参数就是你要的值。顺手把整条 URL 里的file_id、sign也抄下来，凑齐了才能复现一次播放。

办法二：接口响应直读。作品列表接口的返回里，video.play_addr.uri就是 video_id，url_list是拼好的播放地址，直接取用即可，连拼 URL 的步骤都省了。

保存思路：快照 + 白名单裁剪。项目里 node/post/process-post.js 演示的就是这一步：把抓回的原始响应按字段白名单逐层裁剪，只留aweme_id、desc、video、statistics这些项目真正要用的字段，再合并进本地用户视频列表，供 mock 层消费。这样接口字段将来怎么变，改动都集中在数据处理脚本里，前端代码不用动。注意 ⚠️url_list里的 sign 有时效，放久了地址会失效——所以这个项目把数据当一次性快照入库，本地能跑，但链接会随时间慢慢过期，这是快照方案的固有限制，不是 bug。

动手前过一遍这份坑点清单

• 两个 ID 不能互相推导。知道 aweme_id 换不出 video_id，反过来也不行，取数路径完全不同。✅ 正确做法：从同一条接口响应里把两个 ID 一起取走，别指望事后补映射。
• 别拿 aweme_id 去填video_id=参数。播放接口只认v开头的那个值，传错类型必然 403。✅ 正确做法：拼接前先看一眼值的长相，纯数字一律不进播放 URL。
• 别以为裸 video_id 就能播放。缺了 sign，门牌再准也进不了库。✅ 正确做法：用url_list里带 sign 的完整地址，或找服务端现签。
• 快照里的播放地址会过期。演示项目无感，长期服务就会陆续失效。✅ 正确做法：定期重新抓取刷新数据，把"刷新"纳入数据维护流程。
• 文件名前缀不等于字段含义。video_id_*.json里装的是按 aweme_id 拆的评论。✅ 正确做法：判断数据归属看内容里的 key，不看文件名。

一句话收束：这条链路到底是谁在干活

把整条链路串起来就一句话：aweme_id 负责"定位到这条作品"，video_id 负责"指向 CDN 上的那份文件"，sign 负责"证明你此刻有资格按下播放键"。douyin-vue 的聪明之处正在于它刻意不碰后两者的实时环节，把抓好的快照数据交给 mock 层回放，前端就能完整体验无限滑动的视频流，而不用承担签名的时效问题。

想本地跑起来：执行git clone https://gitcode.com/GitHub_Trending/do/douyin拉下代码，进入目录后pnpm install安装依赖，再pnpm dev启动开发服务器，最后把浏览器开发者工具切到手机模式预览，就能看到刷不完的竖屏视频流了。

【免费下载链接】douyinVue3 + Pinia 仿抖音，Vue 在移动端的最佳实践 . Imitate TikTok ，Vue Best practices on Mobile项目地址: https://gitcode.com/GitHub_Trending/do/douyin