企业官网建设流程全解析

Bilibili-Evolved 定制自动连播行为：分场景配置番剧、分P、合集与推荐视频的连播策略

【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved

导读

定制自动连播行为（customAutoPlay）是 Bilibili-Evolved 增强脚本中用于精细控制哔哩哔哩视频页面自动连播逻辑的组件。B 站原生的自动连播开关是全局一刀切的，无法区分"多 P 视频""番剧""收藏夹""稍后再看"等不同视频类型分别决策。本组件将自动连播拆分为 7 种视频类型独立配置，并内置了类型冲突时的优先级裁决逻辑，让"多 P 视频连播到最后 1P 停止""番剧播完最后一集不跳推荐"等精细化需求变成可选配置项。读完本文，你将掌握每种视频类型的连播行为语义、三种行为值（自动/禁用/总是）的差异、推荐视频（列表第一个）的特殊优先级规则，以及从源码层面理解该组件的处理器注册、匹配与执行机制。

组件定位与适用场景

该组件属于 Bilibili-Evolved 的 video 分类组件，其入口元数据定义在 registry/lib/components/video/player/custom-auto-play/index.ts 中，核心特征如下：

• displayName为定制自动连播行为，urlInclude覆盖了videoUrls与bangumiUrls两类页面（即普通视频页与番剧页），只有在这两类页面中组件才会被注入执行；
• 组件内部维护了一个处理器（Handler）注册表，registerHandlers()一次性注册 7 个处理器，分别对应 7 种可独立配置的视频类型；
• 每次视频切换（导航变化）或组件选项变化时，都会重新初始化脚本，重新匹配当前页面适用的处理器并应用连播策略，实现"动态跟随"。

组件注册的 7 个处理器及其对应类型见下表：

三种自动连播行为值

每个视频类型都有独立的配置项，可选值由枚举AutoplayActionType定义（见 AutoplayActionType.ts）：

• 自动：智能判断模式。核心逻辑参考传统连播模式（传统连播模式组件）的行为，即推荐视频都不自动连播；而多 P 视频（番剧、多 P 列表、收藏夹等）会连播到最后一 P 停止。这是大多数场景下的默认推荐值。
• 禁用：完全关闭该类型视频的自动连播，当前视频播放结束后不再跳转到下一项。
• 总是：无条件自动连播，具体行为由 B 站本身的播放逻辑决定。例如分P视频设置为总是时，分 P 播完后会继续自动连播到推荐视频；而番剧设置为总是时，仍会遵循 B 站番剧页的逻辑，播到最后一集停止。

从源码看，三者的判定收敛在基类 BaseAutoplayHandler.shouldAutoplayWithAutoHandler 中：ALWAYS直接返回true，DISABLE直接返回false，AUTO则交给每个处理器自带的回调autoTypeHandler做精细化判断。例如分 P 视频、收藏夹、稍后再看等类型在自动模式下的回调是() => !this.isLastSequentialNumber()——即"当前不是最后一 P 才连播"；而两类推荐视频在自动模式下回调固定返回false（永不自动连播），与文档中"推荐视频都不自动连播"的说明完全一致。

配置项一览与默认值

index.ts中options字段定义了 7 个下拉配置项，全部以dropdownEnum: AutoplayActionType渲染为三选一下拉菜单。默认值如下：

值得注意的是番剧的默认值与其他类型不同：默认即为总是。也就是说在不做任何修改的情况下，番剧页会保持 B 站原生"播完当前集继续播下一集、最后一集停止"的行为，而分 P、收藏夹、合集、稍后再看等默认采用自动智能判断。

页面匹配机制：处理器如何"认出"当前页面

组件每次执行时，会调用BaseAutoplayHandler.getHandlers()，遍历已注册的 7 个处理器，逐个执行各自的match()方法，把匹配当前页面的处理器收集起来（见 BaseAutoplayHandler.ts 的静态方法）。各处理器的匹配逻辑各不相同：

• 番剧：页面 URL 命中bangumiUrls中的任意模式；
• 收藏夹 / 稍后再看：URL 分别命中favoriteListUrls/watchlaterUrls；
• 分P视频：URL 命中普通视频页，且 DOM 中存在.video-pod .multip（分 P 列表）与.video-pod .auto-play .switch-btn（自动连播开关）；
• 视频合集：URL 命中普通视频页，且存在.video-pod .section（合集列表），同时界面是"带自动播放切换按钮的旧版"或"带订阅合集按钮的新版"之一（见isLegacyLayout/isNewLayout）；
• 推荐视频（接下来播放）：普通视频页存在.recommend-list-v1 .switch-btn开关；
• 推荐视频（列表第一个）：URL 命中普通视频、番剧、收藏夹或稍后再看任一页面，且页面中存在推荐列表首个视频链接（.rec-list .pic a等选择器，见getFirstRecommend()）。

匹配成功后，组件会依次调用每个处理器的shouldAutoplay()判断是否应连播，并最终通过setupAutoPlay(enable)落地到页面。落地方式分为两种：多数类型通过操作页面右上角的自动连播开关按钮（调用 Vue 实例的setContinuousPlay，见setupAutoPlay_SwitchBtn），而番剧与新版合集界面则通过点击播放器设置浮窗内的播放方式单选按钮（setupAutoPlay_Player，连播为 value=0，单集为 value=2）。

优先级说明：推荐视频（列表第一个）的特殊规则

自动连播控制是一个"互斥"动作——同一时刻页面只能有一个生效的连播策略，因此多个处理器同时匹配时必然存在优先级冲突。当前机制中，唯一会与其他类型"同时出现"的类型就是推荐视频（列表第一个），它的优先级规则如下：

1. 在所有匹配的处理器中，只有第一个判定为"应该连播"的处理器会被启用，其余全部被置为不连播（见initScript中enableHandler与disableHandlers的分类逻辑）；
2. 推荐视频（列表第一个）的优先级是最低的，它要生效必须同时满足两个条件：自身设置为总是，且其他匹配类型不是总是；
3. 若其他类型也设置为总是，则其他类型优先生效，推荐视频（列表第一个）的设置被忽略。

从实现上看，RecommendListAutoplayHandler.shouldAutoplay()中自动模式固定返回false，只有在总是时才返回true；同时由于处理器注册顺序中它排在最后，天然位于getHandlers()返回列表的末尾，因此在initScript的"首个应连播处理器"抢占逻辑中天然处于劣势，这从代码结构上印证了"最低优先级"的设定。当它被启用时，实现方式是监听video元素的ended事件（一次性），播放结束后直接跳转到推荐列表第一个视频的链接（onVideoEnded中调用window.location.assign）。

联动行为示例表

当推荐视频（列表第一个）设置为总是时，它在匹配页面上会与其他类型（以分P视频为例）联动，最终行为取决于另一类型的设置，见下表：

视频合集内嵌分P的特殊规则

视频合集（Playlist）类型有一层更细的联动逻辑，文档与源码（PlaylistAutoplayHandler.ts）均给出了明确语义：

• 视频合集的某个分集内部如果再内嵌分 P，那么分集内部的 P 与 P 之间切换，由分P视频（multipart）的设置控制；
• 当前分集播放到最后一 P 后，是否继续进入下一个分集，才由视频合集（playlist）的设置控制。

源码中shouldAutoplay()通过getNestedMultipartProgress()解析当前 BV 号在合集列表中对应的分集条目，读取其内嵌.page-list .page-item数量以及 URL 中的p参数，判断是否处于分集内部的中途位置：若当前页小于内嵌总页数，则回落到multipartAutoplayAction配置（自动时返回true，即分集内部默认继续连播下一 P）；否则才依据playlistAutoplayAction决定是否进入下一分集（自动时以"当前分集是否最后一集"为判断依据，即!this.isLastSequentialNumber()）。同时，新版合集界面通过播放器设置浮窗内的单选按钮（setupAutoPlay_Player）实施控制，旧版界面则复用右上角开关（setupAutoPlay_SwitchBtn），兼容两种 B 站界面布局。

从源码理解整体执行流程

综合 index.ts 与处理器实现，组件一次完整的"刷新连播策略"流程可以归纳为：

1. 等待播放器就绪（playerReady()），并取出所有匹配当前页面的处理器（getHandlers()）；
2. 逐个调用shouldAutoplay()，将结果分类为"应启用"与"应禁用"两组，同时保证只有第一个应启用的处理器真正生效；
3. 先统一执行禁用操作（避免后执行的启用被覆盖），再对选中的处理器执行启用操作；
4. 监听右侧面板（.right-container-inner、.playlist-container--right或.plp-r）的子节点变化，经lodash.debounce(initScript, 1000)防抖后重新执行上述流程，以响应 SPA 内的视频切换；
5. 对每个配置项注册addComponentListener，用户在设置面板修改任一选项时立即重新初始化脚本。

值得注意的实现细节是：基类在自动模式下判断"最后一 P"依赖各子类覆写的getSequentialNumberString()与parseSequentialNumbers()——分 P 与合集读取.video-pod__header .amt（形如1/10），收藏夹与稍后再看读取.list-count，番剧则读取.plp-r span[class^=eplist_ep_list_progress]；而番剧的 PV、小剧场等没有分 P 序号的条目会退化为"按播放图标所在条目是否还有下一个兄弟元素"来判断是否最后一集（见BangumiAutoplayHandler.isLastSequentialNumber的覆写逻辑）。这些 DOM 选择器与 B 站页面结构强相关，若 B 站改版，组件需要同步适配。

使用建议与注意事项

• 若希望"多 P 视频 / 番剧 / 收藏夹 / 稍后再看"都严格连播到最后一项即停、绝不跳推荐，保持各类型为自动即可，无需额外设置；
• 若希望分 P 播完后继续连播推荐视频，请把分P视频设为总是；
• 若希望在番剧页保持 B 站原生"最后一集停止"的同时又不想被推荐视频打断，注意番剧默认即为总是，这与推荐视频（列表第一个）的最低优先级规则结合后，番剧播完不会跳转推荐；
• 由于推荐视频（列表第一个）的生效条件苛刻（自身总是+ 其他类型非总是），它更像一个"兜底"策略而非常规配置，使用前请先确认当前页面匹配了哪些其他类型；
• 该组件依赖 B 站页面特定的 DOM 结构与 Vue 实例接口（如setContinuousPlay、播放器设置浮窗单选按钮），仅适用于组件urlInclude覆盖的视频页与番剧页。

文章内容以 custom-auto-play/index.md 的功能说明为骨架，并结合 custom-auto-play/index.ts、AutoplayActionType.ts 及handlers/目录下 7 个处理器源码交叉印证，读者可在设置面板的"视频 → 播放器"分类下找到本组件并即时体验。

【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved