我在html5-boilerplate上看到的模式是:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

它可以在不同的方案上顺利运行，如http, https，文件。

没有方案的相对URL (http:或https:)是有效的，根据RFC 3986:“统一资源标识符(URI):通用语法”，章节4.2。如果客户端阻塞了它，那么这是客户端的错，因为它们没有遵守RFC中指定的URI语法。

你的例子是有效的，应该可以工作。我自己在访问量很大的网站上使用过相对URL方法，没有人抱怨。此外，我们还在Firefox、Safari、IE6、IE7和Opera上测试我们的网站。这些浏览器都能理解URL格式。

不使用协议是完全合理的。URL规范多年来一直对此非常明确，我还没有发现一个浏览器不理解这一点。我不知道为什么这个技巧不为人所知;它是跨越HTTP/HTTPS边界这一棘手问题的完美解决方案。更多信息:Http-https转换和相对url

这的确是正确的，正如其他答案所陈述的那样。但是你应该注意，一些网络爬虫会通过在你的服务器上请求它们来设置404，就像一个本地URL一样。(他们忽略了双斜杠，将其视为单斜杠)。

你可能想要在你的web服务器上设置一个规则来捕捉这些并重定向它们。

例如，在Nginx中，你可以添加如下内容:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

但是要注意，如果在uri中使用句点，则需要增加特异性，否则最终会将这些页面重定向到不存在的域。

而且，对于每个查询来说，这是一个相当庞大的正则表达式——在我看来，对于大多数兼容的浏览器来说，用404来惩罚不兼容的浏览器是值得的。

它保证可以在任何主流浏览器上运行(我没有考虑市场份额低于0.05%的浏览器)。见鬼，它适用于ie 3.0。

RFC 3986定义URI由以下部分组成:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

当定义相对uri(章节5.2)时，你可以省略这些部分，总是从左边开始。在伪代码中，它看起来像这样:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

您描述的URI是一个无方案的相对URI。

有没有什么情况下它不起作用?

如果父页面是从file://加载的，那么它可能无法工作(它将尝试获取file://cdn.example.com/js_file.js，当然您也可以在本地提供)。