问题

用 // 代替 http:// 有什么好处?

回答
用 `//` 代替 `http://`,最直接的好处在于简化了书写,让URL地址看起来更简洁、更短小。但在这背后,其实隐藏着一些更为重要的技术原因和使用场景,让这种“偷懒”变得很有意义。咱们来掰开了揉碎了聊聊:

1. 协议无关性(Protocol Agnostic):这是最核心的优势

想象一下你在写一个网页的链接,里面可能包含指向图片、样式表、JavaScript文件,甚至是其他网页的链接。这些资源的加载协议,不一定总是 `http://`。它可以是:

`https://` (安全协议): 这是现在的主流,用来确保数据的加密传输。
`ftp://` (文件传输协议): 虽然现在用得少了,但过去和某些特定场景下依然存在。
`file://` (本地文件协议): 当你在本地开发,或者引用本地资源时会用到。
`data:` (Data URL): 直接将数据嵌入到URL中,比如base64编码的图片。

如果你在一个页面中,同时需要引用HTTP和HTTPS的资源,并且你的网页本身是通过HTTPS加载的,那么浏览器出于安全考虑,通常会阻止一个HTTPS页面去加载一个HTTP的资源(这被称为“混合内容”问题,Mixed Content)。

这时候,如果你使用 `//` 来开头,浏览器会智能地根据当前页面的协议来决定使用哪个协议去加载这个资源。

如果你的页面是 `https://` 加载的,那么 `//example.com/image.jpg` 就会被浏览器解析为 `https://example.com/image.jpg` 来加载。
如果你的页面是 `http://` 加载的,那么 `//example.com/image.jpg` 就会被浏览器解析为 `http://example.com/image.jpg` 来加载。

好处是什么?

代码更简洁,维护更容易: 你不必为不同的协议写不同的URL。一个 `//example.com/image.jpg` 就能兼容HTTP和HTTPS环境。
避免混合内容警告/错误: 这是最大的福音。通过使用协议相对URL,可以确保你的页面在安全环境下也能正常加载所有资源,不会因为协议不匹配而产生安全警告,影响用户体验或导致资源加载失败。

2. 节省字符,提升效率(虽然微乎其微,但也是好处)

`http://` 需要7个字符,而 `//` 只需要2个。虽然在大多数情况下,这点字符的节省微不足道,但对于那些需要传输大量URL数据的场景(例如,大量的API请求、配置文件等),积少成多,也能带来微小的效率提升。

3. 符合Web标准和最佳实践

在现代Web开发中,使用协议相对URL(以 `//` 开头)是一种被广泛推荐的最佳实践。它能够让你的代码更具适应性,更能应对网络环境的变化和发展。

举个例子,让你感受更直观:

假设你在开发一个网站,并且决定将你的网站从HTTP升级到HTTPS。

未使用 `//` 的情况:

如果你之前在HTML中这样写图片链接:

```html


```

当你的网站切换到HTTPS后,浏览器会尝试加载 `https://cdn.example.com/logo.png` 和 `https://cdn.example.com/styles.css`。如果你的CDN服务器没有正确配置HTTPS,或者你的CDN域名和主站域名不同,而你又没有为CDN设置HTTPS证书,那么这些资源将无法加载,你的网站就会出现样式错乱或图片缺失的情况。你必须手动去修改每一个URL,将 `http://` 改为 `https://`。

使用 `//` 的情况:

而如果你之前这样写:

```html


```

当你的网站从HTTP切换到HTTPS时,浏览器会自动检测当前页面的协议是HTTPS,然后自动将 `//cdn.example.com/logo.png` 解析为 `https://cdn.example.com/logo.png` 来加载。只要你的CDN服务器支持HTTPS(现在绝大多数CDN都支持),这些资源就会无缝地以HTTPS加载,你的网站无需任何修改就能正常工作。

总结一下,用 `//` 代替 `http://` 的好处主要体现在:

最重要的: 实现了协议无关性,能够自动适应当前页面的协议(HTTP或HTTPS),避免了混合内容问题,确保了网站的安全性和资源的正常加载。
简化代码: 让URL更短,书写更方便。
提升维护性: 在协议切换(如从HTTP升级到HTTPS)时,无需大规模修改代码。
符合现代Web开发趋势和最佳实践。

所以,下次你在写URL的时候,特别是引用外部资源或者跨域资源的时候,如果当前页面的协议会影响到资源加载,不妨试试用 `//` 来代替 `http://` 或 `https://`,你会发现它带来的便利和健壮性远超你想象。

网友意见

user avatar

如果你做过「全站 HTTPS 升级改造」,就不会有什么疑问了。

我给全站做 HTTPS 升级的时候,真的想把写 http:// 的人砍死。尤其是数据库里的链接和 JS 里拼接出来的 url。期间用了各种正则,还要人工核查。

奈何写 http:// 的程序员太多,只能作罢。


有人还在评论里问原因,原因就是如果你全写 //,我就不用改造数据库里的数据和源码了,直接升级 https 就行了。你可能会说 https 改造这种事情很少发生吧,巧了,我在腾讯和阿里都遇到了 https 改造 ಥ_ಥ 而且在阿里的时候我要负责 1688 整站(个别部门自行改造)的前端代码改造(不只是 HTML,还有 CSS 、JS、Velocity 模板等!简直就是脏活累活,我 TM 为什么要接这个活儿),你猜我骂写 http:// 的人骂了多少次?

有的前端还直接在 JS 里写 http,沿用一下当前页面的协议你会死啊?

还有的前端用正则判断 url 时居然只接受 http:// 和 https:// 不接受 //,真的是没常识。

太多程序员,太智障了。也有可能是因为他们没听说过 HTTPS 而已。



如果你还不懂,我就问你几个问题:

  1. 如果你用 http:// ,那你就是默认当前页面是 http 协议了,你一个前端凭什么决定当前页面的协议?难道你不知道 http 链接在 https 页面里会报错啊?你应该沿用当前页面的协议,所以你要写 //
  2. 如果你用 https://,也是一样的问题,你怎么知道三年后会不会出现一个 httpshe://,难道到时候你再全部改成 httpshe:// ?
  3. 不要做任何明显是错误的假设!你根本就不知道当前页面会用什么协议打开!所以你要用 // 啊!

类似的错误假设还有很多,比如很多中国程序员都以为电话号码只含数字和括号,不含字母。

真的是这样吗?

那些程序员深信不疑的谣言

那些前端程序员深信不疑的谣言(HTML篇)


这种事情,被坑一次你才会长记性。

或者被我怼几次,看你还写不写 http://




有人说全局替换不就完了吗?

举例说明吧,假设淘宝要升级 https

于是你将 http:// 全部替换成 //

第一个 bug:你把 <a href="http://tmail.com"> 替换成了 <a href="//tmail.com"> ,然而当时 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 至少还有三年呢」然后就写出了垃圾代码。

类似的话题

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有