转载自简书
https://www.jianshu.com/u/dd13775ff7c7
// 缺省协议
//缺省协议的运用，表率资源拜访的协议和当前页面保持一致，倘若当前页面是http ，采用http协议拜访，倘若是https，则运用 https 协议拜访。这般用就不管是http还是升级到https都不用改动代码,此刻非常多CDN资源都是这般引用。通常运用在内链中，外链的协议头拥有不确定性的原由。
//的含义？
//是缺省协议的写法，例如
//https://www.jianshu.com/css/app.css
缺省协议默认运用当前协议
当前页面为HTTP时，等效
http://www.jianshu.com/css/app.css
当前页面为HTTPS时，等效
https://www.jianshu.com/css/app.css
运用 // 代替 http:// 的要求和好处？
当前页面和目的资源同期支持HTTP和HTTPS正在从http升级到https
这般的好处便是能按照用户打开页面的方式自适应的选取资源的请求协议,
针对https页面的内容，浏览器默认会组织非https内容，能够避免这种状况
运用 // 的缺点
直接打开本地文件调试时，运用的协议是文件协议(file://)
这个时候这个协议会变成
file://https://www.jianshu.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:// ？不要做任何显著是错误的假设！你基本就不晓得当前页面会用什么协议打开！因此你要用 // 啊！类似的错误假设还有非常多，例如非常多中国程序员都以为tel号码只含数字和括号，不含字母。真的是这般吗？
有人说全局替换不就完了吗？举例说明吧，假设淘宝要升级 https于是你将 http:// 所有替换成 //第1个 bug：你把 <a href="http：//tmail.com"> 替换成为了 <a href="//tmail.com"> ，然而当时 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://是当初多么明智的决定。。。
发表于 2024-8-4 14:50:17
