抖音视频播放解析：aweme_id 与 video_id 的分工
【免费下载链接】douyinVue3 + Pinia 仿抖音，Vue 在移动端的最佳实践 . Imitate TikTok ，Vue Best practices on Mobile项目地址: https://gitcode.com/GitHub_Trending/do/douyin
手里攥着一个 19 位数字，以为万事俱备，往浏览器一贴却发现画面毫无动静。在 douyin-vue（Vue3 + Pinia 实现、支持无限滑动视频播放的仿抖音项目）里，每条视频记录都同时带着两个标识：aweme_id 与 video_id。前者负责查询标题、作者、评论这类元信息，后者才用于视频播放时取回真实码流，搞混两者的角色是接触抖音数据时最常踩的坑。
两个编号各管什么
先给结论：两个编号是"作品"与"文件"两条平行标识，谁也推导不出谁。用寄快递来类比，aweme_id 是作品的身份证号，video_id 是视频文件的快递单号——身份证号能在任何柜台查档案，单号只能用来取件，两者从不通用。
| 维度 | aweme_id（作品身份证号） | video_id（文件快递单号） |
|---|---|---|
| 形态 | 19 位纯数字，如7265649807396474112 | v开头加字母数字，如v0300fg10000cna0c8bc77ufge7emlsg |
| 职责 | 唯一标识"这是哪条作品"，查详情、评论、作者列表的接口入参 | 唯一标识"CDN 上哪份文件"，拼接播放地址的核心参数 |
| 在数据中的位置 | public/data/videos.json 每条记录的顶层字段 | 藏在video.play_addr里：uri字段，以及url_listURL 的video_id参数 |
| 能否互相推导 | 不能 | 不能 |
这里还藏着一个命名陷阱：public/data/comments/ 下的video_id_7260749400622894336.json这类文件名，后缀数字其实全是 aweme_id，"video_id_"前缀只是历史命名。
📡 一次播放请求的生命周期
播放地址不需要现场拼，快照里早已备齐，直接喂给<video>标签即可。video_id 并不是顶层字段，它在video.play_addr里以两种形态出现：
{ "uri": "v0300fg10000cna0c8bc77ufge7emlsg", "url_list": ["https://www.douyin.com/aweme/v1/play/?video_id=...&file_id=...&sign=..."] }uri：video_id 本体，即这份文件的"单号"。url_list：服务端拼好的完整播放地址，除video_id外还带着file_id（文件指纹）与sign（时效性签名）。
sign 的存在说明一件事：video_id 单独换不回文件，它必须配着 sign 才能取件。而这个签名会过期，所以项目直接存完整 URL 列表，不存裸的 video_id 让你现场拼。
完整链路四步走：
- 前端 src/api/videos.ts 发起请求，如
recommendedVideo()请求/video/recommended，职责只是"发请求、收数据"。 - src/mock/index.ts 用 axios-mock-adapter 拦截这些请求，从本地
allRecommendVideos（初始为打包的 src/assets/data/posts6.json，启动后还会拉取 public/data/videos.md 合并进来）按页切片返回。 - 组件拿到数据后直接消费
url_list，对应代码在 src/components/slide/BaseVideo.vue：
<video :autoplay="isPlay"> <source v-for="(urlItem, index) in item.video.play_addr.url_list" :src="urlItem" type="video/mp4" /> </video>- 浏览器请求该 URL，码流开始播放。file_id 与 sign 只是 URL 里的参数，前端从不计算它们。
为什么 mock 层不实时拼地址
因为项目刻意把"查数据"和"播放"拆成两条互不交叉的泳道，而实时拼地址恰好是前端做不了的那一步。
- 查询泳道（以 aweme_id 为键）：点击评论入口时用
props.item.aweme_id请求/video/comments，mock 层去 public/data/comments/ 找video_id_{id}.json；这些小文件由 node/comment/process.js 按 aweme_id 从大份评论 JSON 里逐条过滤拆分而来。 - 播放泳道（以 video_id 为键）：
play_addr.url_list直接进<video>标签，中间没有任何拼接步骤。
不实时计算不是偷懒，是硬约束：能播的地址必须有有效 sign，它只能由抖音服务端签发且有时效，纯前端演示拿不到实时签名。于是"一次抓快照、反复回放"成为唯一自洽的方案，代价是数据带保质期——地址会随时间陆续失效，项目因此把数据定位为一次性快照，而非长期信源。
📦 自己备数据的最短取数路径
接口响应是最省事的来源：拿到作品列表接口的原始响应后，video.play_addr.uri就是 video_id，url_list就是拼好的播放地址。node/post/process-post.js 演示了整理动作——把原始aweme_list按字段白名单裁剪，只保留play_addr等项目需要的部分，再合并进本地用户视频列表供 mock 层消费。
两点提醒：
- 别把 aweme_id 填进
play/?video_id=参数，它只认 video_id，传错类型必然失败。 - 地址里的 sign 有时效，长期服务要考虑定期刷新，演示用途则一次性快照足够。
小结
整条链路一句话收束：aweme_id 负责找到作品，video_id 负责找到文件，sign 负责证明你此刻有资格播放。douyin-vue 不触碰其中任何一步的实时逻辑，只把快照交给 mock 层回放，前端即可完整体验无限滑动的视频流。
git clone https://gitcode.com/GitHub_Trending/do/douyin cd douyin pnpm install pnpm dev【免费下载链接】douyinVue3 + Pinia 仿抖音，Vue 在移动端的最佳实践 . Imitate TikTok ，Vue Best practices on Mobile项目地址: https://gitcode.com/GitHub_Trending/do/douyin
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
