//預設協議
/預設協議的使用，代表資源訪問的協議和當前頁面保持一致，如果當前頁面是http ，採用http協議訪問，如果是https，則使用 https 協議訪問。這樣用就不管是http還是升級到https都不用改動程式碼,現在很多CDN資源都是這樣引用。一般使用在內鏈中，外鏈的協議頭具有不確定性的原因。
//的含義?
//是預設協議的寫法，例如
//baiid.net/css/
預設協議預設使用當前協議
當前頁面為HTTP時，等效
http://baiid.net/css/
當前頁面為HTTPS時，等效
https://baiid.net/css/
使用 // 代替 http:// 的條件和好處?
當前頁面和目標資源同時支援HTTP和HTTPS正在從http升級到https
這樣的好處就是能根據使用者開啟頁面的方式自適應的選擇資源的請求協議,
對於https頁面的內容，瀏覽器預設會組織非https內容，可以避免這種情況
// 缺點
直接開啟本地檔案除錯時，使用的協議是檔案協議(file://)
這個時候這個協議會變成 file://baiid.net/css/顯然是不存在的
與當前網站的協議保持一致，快速釋出與你當前協議相匹配的版本，同時減少SSL或其它協議版本的部署成本。開發者不需要管伺服器雲端提供什麼協議，只要用//符號來代表一切最適應的匹配，這和nodeJS的思維是一脈相承的。
優點如下：
因為很多網站都將http升級為https，這樣就可以防止我們的網址被劫持，前期為了在轉換過程中我出差錯我們沒有強制跳轉,就是當使用者訪問http或https都可以正常訪問，那麼裡面的js，圖片，連結等都不能用https或http，那麼有什麼解決方法呢，那麼解決方法來了就是用//，不要帶http:與https這樣就可以了。
//這種寫法是根據你請求的協議自動新增協議的。舉個例子：你的網站是http協議，那麼其實你訪問的就是http://xxxx 如果你的網站是https協議的，那麼請求的地址會變成https://xxxx 要知道，如果你寫成了http://xxx. 那麼如果你們的網站線上是https，那麼可能會報安全警告，有的瀏覽器甚至沒法正常載入頁面。如果你直接寫成https，要知道，本地開發可是http啊...
下面的內容是來自知乎的一些經典回覆
好處很多人都答過了。升級 https 當然最能感受到這種好處。我只是補充一個為什麼前人不這麼寫的理由。當然，確實有很多前端並不知道這種寫法。不過，就算知道也很可能無法這麼寫。因為 UC 瀏覽器的許多較早版本不支援這種寫法，會把 //a.b/ 直接理解為 /a.b/，也就是說，如果你在 http://example.com 的頁面裡寫了 //example-cdn.net/static-file 的地址，UC 實際訪問的是 http://example.com/example-cdn.net/static-file 。UC 過去的市佔率大家是知道的。所以……
一看你就沒做過「全站 HTTPS 升級改造」。我給全站做 HTTPS 升級的時候，真的想把寫 http:// 的人砍死。尤其是資料庫裡的連結和 JS 裡拼接出來的 url。期間用了各種正則，還要人工核查。奈何寫 http:// 的程式設計師太多，只能作罷。有人還在評論裡問原因，原因就是如果你全寫 //，我就不用改造資料庫裡的資料和原始碼了，直接升級 https 就行了。你可能會說 https 改造這種事情很少發生吧，巧了，我在騰訊和阿里都遇到了 https 改造 ಥ_ಥ 而且在阿里的時候我要負責 1688 整站(個別部門自行改造)的前端程式碼改造(不只是 HTML，還有 CSS 、JS、Velocity 模板等!簡直就是髒活累活，我 TM 為什麼要接這個活兒)，你猜我罵寫 http:// 的人罵了多少次?有的前端還直接在 JS 裡寫 http，沿用一下當前頁面的協議你會死啊?
還有的前端用正則判斷 url 時居然只接受 http:// 和 https:// 不接受 //，真的是沒常識。太多程式設計師，太智障了。也有可能是因為他們沒聽說過 HTTPS 而已。如果你還不懂，我就問你幾個問題：如果你用 http:// ，那你就是預設當前頁面是 http 協議了，你一個前端憑什麼決定當前頁面的協議?難道你不知道 http 連結在 https 頁面裡會報錯啊?你應該沿用當前頁面的協議，所以你要寫 //如果你用 https://，也是一樣的問題，你怎麼知道三年後會不會出現一個 httpshe://，難道到時候你再全部改成 httpshe:// ?不要做任何明顯是錯誤的假設!你根本就不知道當前頁面會用什麼協議開啟!所以你要用 // 啊!類似的錯誤假設還有很多，比如很多中國程式設計師都以為電話號碼只含數字和括號，不含字母。真的是這樣嗎?
有人說全域性替換不就完了嗎?舉例說明吧，假設淘寶要升級 https於是你將 http:// 全部替換成 //
第一個 bug：
你把 替換成了 ，然而當時 http://tmail.com 還不支援 https於是你將一定範圍內的域名替換，http：//(taobao|taobao2|taobao3).com 替換成 //$1.com
第二個 bug：
有些 JS 是這樣寫的 url = "http://" + location.hostname + '/' + path，還有寫 JS 是這樣寫的 /^http://///.test(input)。你說這個就沒法用正則了，在所有 JS 裡全域性搜尋 http 然後人工審查吧。你知道淘寶有多少 JS 檔案嗎…… 而且這些檔案是快取十年的……就算你改了，也不一定能更新。而且一旦你改錯了，影響使用者下單，馬雲損失一個億你賠得起嗎?
第三個 bug：
有些資料根本就不在程式碼裡，在資料庫裡，比如 user.image 的值是 http 開頭的。於是你將 user.image 寫成 user.image.replace('http://', '//') 或者你直接改資料庫裡的資料(當資料量很大的時候，這基本是不可能的)
第四個 bug：你忘了改 nginx、crossdomain 裡面的域名第五個 bug：你忘了改配置系統裡面的 base_url第六個 bug：你的 https 頁面嵌入了一個外部的 http iframe……你就哭吧，這很難解決，運氣好直接改成 // (外部支援 https 即可)，運氣不好就要改頁面邏輯了。
第 N 個 bug……
HTTPS 升級就是髒活累活，你說簡單你來做，你開始做就知道牽連的地方有多少了。最好的方案還是把協議做成很容易變更的方式，比如遵循當前頁面，或者用變數，反正寫死 http:// 肯定不好。有些程式設計師寫程式碼的時候，明明知道有 HTTPS 卻不去相容，心理想著「反正我在這個公司呆兩年就走了，HTTPS 至少還有三年呢」然後就寫出了垃圾程式碼。
越來越多的開發者，在連結檔案時，採用//來代替http://，即如< a href="http://baiid.net……一般寫為 < a href = " //http://baiid.net……，這與傳統帶http有什麼區別?
原本你的網站是http的，所有的src都是 http開頭,以為遭到狗屎運營商大量劫持，在你的頁面塞了一大堆少兒不宜/和單純廣告的內容的時候，有人告訴你替換https可以改善這個問題，那麼這個時候你就知道 之前的src和ajax寫得//而不是http://是當初多麼明智的決定。。。
逐浪CMS官方
隨著越來越多開源和雲平臺的湧現以及SSL協議的廣泛匯入(如逐浪CMS已經全面啟用了SSL協議支援)，人們在進行開發時不得不面對http協議的選擇和識別。眾所周知，過多的ssl引用，可能會造成普通站點的效率低下，但我們不能為此再去重新設計一個純SSL版本。表現在開源庫上，一般平臺都同時提供SSL版和非SSL版。如這兩個庫：https：//code.z01.com/js/jquery-3.2.1.slim.min.js
http：//code.z01.com/js/jquery-3.2.1.slim.min.js
其引用效果是一致的。於是開發者們直接用"//網址/檔案"方法來替代前面的協議，使之自動識別。即具體是SSL協議還是普通http協議，交給瀏覽器去自動識別並自動與當前站點匹配，從而實現最佳的安全請求和最高效的載入方法。概言之，這是一種開發方法和開發思維，雲端計算的web與移動開發日益壯大。