背景介绍
公司目前的业务需要用到播放直播视频, 视频流是通过第三方某某云服务器，拉取到本地的，然后使用播放器播放。
天坑之前
本人是前端er,负责web端视频播放。
在通过接口拿到云端的视频流播放地址后，我首先使用的鼎鼎大名的videoJs这个浏览器端的播放器王者。
一切都正常使用，拿到流怼到videoJs播放器里面也能顺利播放。可是，播放了一段时间后，某明奇妙的卡壳，终端，事件监听不准确等问题体现出来。查找各种问题流程，都是按照文档使用，没有毛病啊。后面把拉取的流也放在他们云端播放器播放，能正常播放。这就很奇怪了……
在跟他们第三方云服务器工程师沟通后，他们表示确实是有些问题，但是他们也不知道为什么，需要我们自己去解决。这样的售后，哎，谁叫他们便宜呢。
然后我强压怒气的反问道，为什么使用我们的播放器插件就不能正常的播放，而在你们的云端就能正常的播放昂。你们用的什么播放器。售后人回答道:“这是我们自己根据videoJS二次开发的播放器，更好的兼容我们的视频流，不过现在已经没有维护了”。 我说你们既然有这么好用的东西，不早点拿出来。赶紧分享过来，哈哈。
天坑体现
拿到他们的分享过来的视频播放器，我如获珍宝，立马按照文档（说是文档，其实就是一个很简单的代码示范案例）使用了起来。
引用，初始化，拉流，播放流。一气呵成。
果然牛，真的比之前的效果好了很多，根据生命周期，完成一系列的操作效果。
》上效果图：
效果还是比较理想化！！！ 算是大功告成。
打包，发布测试。 经过测试工程师一段时间的测试，发现视频直播一段播放完后，由于已经拉不到流了，所以会一直卡在这个画面不动，这样给用户的体验非常不友好，不知道发生了什么情况。如下图所示：
控制台的日志信息
网络请求已经请求不到资源了。
但是：
通过他们的给的案例和文档，所有的监听事件我都用了，根本就没有视频播放完，拉不到流的事件通知。本着对公司负责，对用户负责的态度，我决定一探究竟。 把他们的插件库下载到本地，去看看源码；
初探插件源码
进来就直接懵逼状态，密密麻麻压缩过的代码，格式化后。拉到最后，竟然有16431行代码；
这也太多了吧，还是放弃好了，管他什么用户体不体验，公司负不负责呢，能播放就行啦。
哈哈， 开个玩笑。都走到这步了，肯定不能轻易放弃呢！
我想，既然只打印了日志，却没有发送事件通知。那就从这里开始，于是我就打了个debugger,决定打印日志那里一探究竟
上面浏览器控制台最后播放完拉不到流的时候，打印了个 handle hls error!， 就从这个关键词开始搜索，从这里，我就打个断点运行看一下啦……
断点走到Switch里面
response是undefined，这个是正确的，从上面的network就可以看出，刚好匹配，所以走到下一个if判断
走到这里的时候，fatal为false,然后就直接return了。所以就可以解释，为什么当点播流播放完时，拉不到流后，控制台会打印个错误信息，然后没有事件通知。这里就会导致用户体验很不好，前端没有合适的机会去告诉用户。
问题找到了，所以，这里我采用插件里面的发布订阅者模式，共用他们定义好的error事件，发送一个错误事件，定义好message信息，来告诉前端，视频拉流已经完成了。
然后视频播放完的时候，就能收到事件通知啦。然后再根据这个通知，告诉用户。再也不会像之前那样，停留在最后一帧啦，一动不动了。
填坑完成
整个坑就算这样填完了。用户体验也上升了一个档次。 文章中写的一气呵成，实际在开发中，还是走了很多弯路，查了很多相关的资料，最终才得以完美的解决掉。
这就是工作遇到的难题，从发现，到懵逼，到解决。记录下来，下次面试，再也不怕面试官突然来句，你工作中遇到什么难题，怎么解决的问题了！！！
