背景
在自己研发的手机APP上（Android tbs x5webview/iOS wkwebview）打开H5页面，页面上使用了video播放视频，当进入其它页面或返回上级页面，又或者暂停播放的时候，视频的缓冲并未停止，还在持续下载。
初级解决方案
我们在页面退出的时候，把video节点的src属性设置为""，或者根据[MDN官方文档](!https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery) `Stopping the download of media`这一小节的描述，使用removeAttribute移除src属性。
此时在电脑的浏览器devtool里面inspect手机上的页面，看network栏，确实是停止下载视频数据了，万事大吉！
然后悲剧发生了，某人测试突然发现访问了几个页面之后，数据流量消耗了5.4G，于是问题爆发了。
使用抓包工具，发现确实无论在Android还是在iOS上，视频缓冲的下载都没有停止。
爬坑
然后开始了爬坑之旅，折腾了近两天，被残酷的现实打败了，只能使用最初想到的一个弱弱的方案解决问题，这里记录一下以共勉
iOS
在H5层面折腾了很久，排除了各种vue组件的影响之后，仍然没有解决问题，只能回归到native去找原因。用纯净的wkwebview发现没有这种问题，然后逐步定位发现是拦截器造成的。
对于http服务器上的视频资源(mp4，m3u8等)
只要使用了
[NSURLProtocol wk_registerScheme:@"http"];
无论你
(BOOL)canInitWithRequest:(NSURLRequest *)request
中返回的是YES还是NO，缓冲视频的下载都不会终止，会一直持续到下载完整个视频。
如果上述函数返回YES，在startLoading/stopLoading中还需要做相应的处理，亦没有终止下载。（由于时间关系并没有在这一块深挖，或许有机会完美的实现渐进式缓存机制）
Android
只要使用了X5内核的webview，无论你怎么设置参数，它都是一口气把整个视频给缓存下来。可以直接使用QQ浏览器对页面进行访问，用抓包工具进行测试。
如果是用Chrome的话，抓包工具中的现象是虽然数据连接还处于接受数据的状态，但是下载的字节数却是不会增长了，个人猜测应该是没有断开连接，只是没有继续处理连接上收到的数据了而已。
最后只能绝望的放弃。
终极武器
从H5到Native再绝望的回归到H5，上面寥寥数语，确是我们经历了进两天的被折磨之后得出的结论，在H5上寻找解决方案的时候，我不得不拿出我的最初的一个想法来尝试，结果，嘿，好了～～尼玛……
这个终极武器是怎样的呢？其实很简单，直接将player.currentTime设置为player.duration，意思就是相当于seek到最后一秒。考虑到可能会有循环播放的情况存在，在设置之前先调用pause()暂停播放。
这个方案只能说是目前没有办法的办法，并不安全，更不完美，在我严重它简直丑陋至极，但是没办法，从H5到Native转了一大圈也没有什么能够对视频下载有所控制的方案，只能先凑活用它了。