我搁那看视频呢，然后UP主念结束语的时候看到下面推荐里面有 好 康 的，于是我就点进去看。
很简单对吧，但是这时候诞生了一个巧合。恰好在这个我点击的时间区间内，也就是这个视频播放完然后客户端的代码行为准备去切下一个视频的时候恰好被打断去我点击的另一个视频，然后引发播放器状态丢失问题。
客户端版本8.83.0(release-b23203277)，也就是当前市场包最新版本。
管你听没听懂，看就完了：

这里我是出现了bug才录制的，毕竟谁都不知道这样操作刚好无意中测出来一个bug啊。可以看到效果是黑屏但有音频，画面完全看不到，进度条也出不来。 我开始回想刚才的操作，大概是这样：

在合集里面当前视频播放完然后即将切换下一个视频的时候点击推荐里的视频，会让跳过去的视频有音频没画面。甚至进度条都点不出来

那么这就简单了，有复现方法了就要可以去复现了……吗？错啦没那么简单，这玩意很吃操作的。因为需要恰好视频播放完又恰好播放控制相关代码即将切换然后又恰好在这个时候点击让跳转打断这个状态切换，我的天这buff叠满了。（我怎么把运气给浪费在这上面了）
向来严谨的我肯定想去尝试一把了，当然我一试，发现了新的问题：

这次我卡了一次出来了。不过和之前不太一样的是这次能出现进度条了(虽然是0秒空气视频)，而且有中间的缓冲加载。也就是说这不是完全黑屏的一个状态，它有进度，也有加载。说明它在另一个时间区间内没有完全丢失状态。也就是说这个比上面那个完全卡死黑屏却还在播放的情况好卡一点哈哈。这里的细节是跳转后的视频 **直接返回**

那么可能有人会问了：啊嘿壳嘿壳，你这设备有root也有Lsposed，怎么确保不是这些影响了环境或者改变了一些行为呢？
那么好，我换一台设备给你测试。这台华为手机是没有root权限的，当然也没办法root。完全可信的环境这次总该公平了吧：

我嘞个，这次连7分钟的0秒视频都出来了，看样子时间因素也能影响状态的丢失程度。另外这个我尝试卡了三次才出一次，难度可见一斑。细节是这次跳转后的视频 **暂停** 后按下返回。 如果你还是有异议的话你自己去测，只不过太吃操作了而已。方法基本上就这些，估计深挖还会有不同的表现。

我测试所使用的两个设备分别是一加的PKX110(有root)和华为的CDY-AN00(没解bl)。关键是上报用的小程序里面设备信息只能填一个，总不能融合一下写个《华加手机》吧。所以最终俩设备我二选一写的（提交系统设计的时候就没考虑到有人会多设备测试吗）。
最终目前该问题已提交，啥时候修不一定哈哈

总结一下，这个bug大概率是由视频切换时的代码竞态条件所引发的状态预期行为不一致问题。
最小可复现步骤：
1.找一个视频比较多的合集
2.合集中间随便找个视频
3.把这个视频进度条拖到剩十秒左右结束的时候
4.盯着进度条，满了一瞬间感觉要跳下一个的时候点击下面的推荐视频（重点：要快！）
5.观察跳转过去的推荐视频的播放行为
6.按下返回键回去，观察合集视频的播放行为
（细节：你可以在返回之前决定跳转过去的视频是否暂停，有可能回到合集视频后的表现会不一样）

就这样，一个巧合引发的乌龙就这样梳理完了。问题很简单一般就是代码竞争，两边都跳。如果B站做好边界判断应该就没问题了，或者对这个巧合场景单独做优化和适配。