背景
在自己研發的手機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轉了一大圈也沒有什麼能夠對視頻下載有所控制的方案，只能先湊活用它了。