可能重复：
使用前导双斜杠继承 URL 中的协议有什么缺点吗？即src="//domain.com"</a>
我在很多地方都看到了以下逻辑，f.ex 分析脚本：
script.src = ('https:' == document.location.protocol ? 'https' : 'http') +
'://example.com/cdn.js';
但据我所知，您也可以这样做：
script.src = '//example.com/cdn.js';
它应该使用当前使用的任何协议。还是我错过了什么？什么被认为是“最佳实践”？
我不是在寻找浏览器兼容性的答案，谷歌已经推荐//了 CDN 脚本，所以这里不应该是这种情况。
一点背景：
额外的 JavaScriptprotocol包装器通常用于确保所有浏览器都支持此类relative path URLs。假设大多数当前浏览器无论如何都正确处理此类 URL 是正确的，但是为了能够安心入睡，假设并非所有访问您网页的用户代理都一样精明，这仍然被认为是一种好习惯正如我们所期望的那样（或者，支持RFC 1808第 4 节、RFC 2396第 5.2 节或RFC 3986第 5.2 节，如使用前导双斜杠在 URL 中继承协议有什么缺点吗？线程中已经提到的）正如@Bruno 在评论中指出的那样）
兼容性问题：
想象一个场景，其中包含此类相对路径的内容可以“脱离上下文”访问，例如在电子邮件客户端中。在这种情况下，这样的相对路径可能会以错误的方式解析为其完全限定的路径，并导致各种问题，从用户无法正确查看内容到访问他们确实不应该访问的内容。为避免任何此类问题，应始终将相对路径的使用限制在父文档（打开器应用程序）的解析器可以确定相关资源的完整绝对路径的上下文中。只有当它们将被相同或兼容的协议访问时，您才应该期望相对路径能够正常工作。
安全问题：
提出的另一个可能的担忧是：
是否可以通过各种交换协议访问（解析的 URL）父文档内容以任何方式利用此类相对协议 URL，并且此类 JavaScript 包装器是否用于转移此类访问的目的。
官方 IANA 注册 URL 方案的（长）列表表明，漏洞利用者可能会使用许多令人担忧的交换协议，但是JavaScript 不会对不支持 JavaScript（或被用户禁用）。考虑到这一点，我的回答必须是 -否（对于“使用其他协议保护访问的 JavaScript”部分）。
至于提出的问题的其余部分（“可以以任何方式利用此类相对协议 URL”），答案取决于在设置服务于任何此类内容的 Web 服务器时考虑到这一点的程度，它甚至支持/处理此类请求（如果没有，则不是问题），以及在部署之前考虑了哪些可能的攻击/内容盗窃媒介。换句话说，这是一个网络服务器管理问题，当然不是网页设计师/程序员可以/应该回答的问题。每个最终用户可访问的协议都应该有自己的一套安全协议。