bilibili-parse 上手：一个 URL 拿到 B 站视频直链，PHP 部署与参数避坑指南

【免费下载链接】bilibili-parsebilibili Video API项目地址: https://gitcode.com/gh_mirrors/bi/bilibili-parse

朋友想把 B 站上一个系列教程嵌入自己的自建网站，卡在了"拿不到视频真实播放地址"这一步。最后帮他装好的是bilibili-parse——一个把 B 站视频接口封装成"一个 URL 即可调用"的 PHP 解析工具，不用登录、不用填表单，浏览器地址栏就能拿到可播放的视频直链。下面按我实际的踩坑顺序，带你从部署一路走到会用。

5 分钟跑通：最小可运行的部署

这个项目依赖很轻：PHP 5.4 以上，装了 Curl 和 OpenSSL 扩展即可，不需要数据库，也不需要 Composer。

git clone https://gitcode.com/gh_mirrors/bi/bilibili-parse

把克隆下来的文件原样上传到 PHP 服务器（本地调试也可以用php -S localhost:8000起个内置服务器），项目结构一共就三层：

• index.php：入口，负责接收参数和返回结果
• src/Bilibili.php：核心解析逻辑，封装了对 B 站接口的全部请求
• public/dplayer.html：现成的播放器演示页

部署完直接发一个请求试试：

curl "http://你的域名/index.php?av=23902252&p=1&q=64&otype=json"

几秒钟后会返回类似下面的 JSON（url为方便展示已截断签名参数）：

{ "code": 0, "quality": 64, "url": "http://cn-hbwh-cmcc-bcache-05.bilivideo.com/upgcxcode/...flv?e=...&deadline=..." }

code为 0 表示解析成功，url就是可以直接拿去播放或下载的视频直链。到这里，一个能用的 B 站视频解析服务就跑起来了。

一个 URL 看懂全部参数：怎么选才不会糊

把请求拆开看，index.php认的参数并不复杂，常用的就这几个：

参数之间是独立可组合的，比如分 P 的番剧可以这样写：

/index.php?ep=345646&p=2&q=80&otype=json

两点值得注意。第一，q 只是"期望值"，不是"保证值"。解析时会先看视频实际支持哪些清晰度，如果你要 80 但视频最高只有 64，会做向下修正，或者直接返回"清晰度受限"的提示。第二，av 和 bv 是同一视频的两种编号，给一个就行；cid作为补充参数也能直接指定，属于进阶用法，普通场景用不上。

三种输出，对应三种用法

otype决定了结果长什么样，实际对应三个场景：

• json（默认）：返回完整解析结果，适合程序集成，你在服务端拿到url字段再做后续处理。
• url：不包 JSON，直接吐一个纯文本直链，适合在脚本里快速取值。

curl "http://你的域名/index.php?av=23902252&otype=url" # 直接输出一行 https://... 直链

• dplayer：不走解析流程，直接把public/dplayer.html这个页面返回给浏览器。页面加载 DPlayer 播放器后，自己再去请求一次format=mp4的 json 结果并开始播放，相当于附赠了一个开箱即用的播放器演示页。

format的选择则和画质与平台挂钩：flv单文件直链最省事、兼容性最好；mp4走的是网页端 html5 通道，清晰度限制更严格；dash返回的是视频和音频两条独立地址，适合追求自适应码率的场景，但要自己处理音画合并，新手不建议首选。

为什么缓存能让重复请求提速

每次解析都要向 B 站接口发请求，同样的视频反复解析显然是浪费。src/Bilibili.php内置了缓存能力，入口文件里默认是注释掉的，按需打开即可：

// 开启文件缓存，缓存 1 小时 $bp->cache(true)->cache_time(3600); // 服务器支持 APCu 扩展时，可换成内存缓存 $bp->cache(true, 'apcu')->cache_time(3600);

开启后，同一视频的解析结果会按清晰度_格式存到cache/cid/目录下的 JSON 文件里（比如仓库里的23902252_64_flv.json）。缓存有效期内第二次请求不再触碰 B 站接口，直接读本地文件返回，响应时间几乎为零，对高并发或反复访问同一视频的场景提升非常明显。注意cache_time最小值是 60 秒，想设更短是不生效的。

新手最容易踩的四个坑

坑一：清晰度受限报错。返回"视频清晰度受限，可能需要会员"不代表工具坏了，而是该视频的高画质需要大会员。把q降到 32 或 16 重试即可。

坑二：直链拿到了，播放却失败。B 站的视频地址有防盗链校验，直链需要带Referer: https://www.bilibili.com/请求头才能正常播放。自己写播放器时记得加上，否则会看到"无法加载"之类的报错。这也是 DPlayer 页面里特意设置了meta referrer为never的原因。

坑三：文件缓存不生效。文件缓存要求cache/cid/目录存在且可写，很多服务器上传时没带上空目录，或者目录权限不足，导致缓存静默失败。开启缓存前先确认目录状态。

坑四：项目依赖 B 站公开接口，接口会变。这是所有此类解析工具绕不开的"上游风险"。B 站接口结构一旦调整，返回的字段可能解析不到，导致"获取信息失败"。遇到这种情况先确认不是自己参数写错，再考虑升级或等待作者跟进。

什么时候该用、什么时候别用它

bilibili-parse 适合这些场景：个人网站或博客嵌入 B 站视频、学习 PHP 如何封装第三方 API、内部工具里做视频地址转换——它单文件、无依赖、一个类搞定所有逻辑，阅读和二次开发成本都很低。

它不适合这些场景：把付费内容（大会员番剧、课程）打包分发，这既有版权风险，接口层也过不去；高频批量爬取下载，容易被风控，也违背工具作者的使用预期；对解析稳定性有严格 SLA 的生产系统，因为依赖方（B 站接口）你控制不了。

作为一个小而美的开源项目，它把"解析 B 站视频"这件事压缩到了极致——一条 URL、一个类、三分钟部署。如果你恰好有"把 B 站内容搬到自己的地盘"的需求，它会是成本最低的起点；而把它的边界（清晰度限制、防盗链、上游接口变动）提前看清楚，用起来才不会措手不及。

【免费下载链接】bilibili-parsebilibili Video API项目地址: https://gitcode.com/gh_mirrors/bi/bilibili-parse