转载自简书https://www.songma.com/u/dd13775ff7c7

// 缺省协议

//缺省协议的使用，代表资源访问的协议和当前页面保持一致，假如当前页面是http ，采用http协议访问，假如是https，则使用 https 协议访问。这样用就不论是http还是更新到https都不用改动代码,现在很多CDN资源都是这样引用。一般使用在内链中，外链的协议头具备不确定性的起因。

//的含义？

//是缺省协议的写法，例如

//https://www.songma.com/css/app.css

缺省协议默认使用当前协议

当前页面为HTTP时，等效

http://www.songma.com/css/app.css

当前页面为HTTPS时，等效

https://www.songma.com/css/app.css

使用 // 代替 http:// 的条件和好处？

当前页面和目标资源同时支持HTTP和HTTPS正在从http更新到https

这样的好处就是能根据客户打开页面的方式自适应的选择资源的请求协议,

对于https页面的内容，浏览器默认会组织非https内容，可以避免这种情况

使用 // 的缺点

直接打开本地文件调试时，使用的协议是文件协议(file://)

这个时候这个协议会变成 file://https://www.songma.com/css/app.css显然是不存在的

不过，相对于整站更新的便携性，这点问题可有可无了。

使用 // 的优点

• 与当前网站的协议保持一致，快速发布与你当前协议相匹配的版本，同时减少SSL或者其它协议版本的部署成本。开发者不需要管服务器云端提供什么协议，只需用//符号来代表一切最适应的匹配。
• 由于很多网站都将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: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的，所有的src都是 http开头,以为遭到狗屎经营商大量劫持，在你的页面塞了一大堆少儿不宜／和单纯广告的内容的时候，有人告诉你替换https可以改善这个问题，那么这个时候你就知道 之前的src和ajax写得//而不是http://是当初多么明智的决定。。。