这是curl官方网站上给出的链接：
（省略前缀）bintray.com/artifact/download/vszakats/generic/curl-7.46.0-win64-mingw.7z
当我使用前缀 http:// 和 https:// 下载它时，我得到了两个不同的文件。
我的问题是为什么这个站点提供两个不同的文件——一个通过 HTTP，一个通过 HTTPS？SHA256 哈希不匹配。
这是重定向后最终 URL 的差异。左边的 URL 是 HTTP 重定向到的 URL，右边的 URL 是 HTTPS 重定向到的 URL：
更新：
这两个文件不是同时下载的，但它们的版本号相同，所以我认为它们应该是相同的。不是这种情况。作者告诉我有些修订没有得到新的版本号。在不同日期从站点提供的文件的扫描结果（12/05/15是通过 HTTP 下载的扫描日期，12/ 28 /15是通过 HTTPS 下载的扫描日期）导致混淆，因为版本数字没有改变，但 SHA256 哈希值改变了。
简单的答案是：因为它想！Web 服务器可以通过配置或巧合提供任何它喜欢的服务。
现在，我通过 HTTP 和 HTTPS 获得了相同的 75916c7b 文件，并且无法证实您的理论，即 Web 服务器为 HTTPS 和 HTTP 提供不同的内容。但是，如果您在文件更新时间附近设法访问该站点，则很可能是不同的服务器正在为不同的协议提供服务，并且文件更新尚未传播到为您提供旧文件的服务器。
请记住，一个 URL 可以由任意数量的服务器提供服务——您从一个 URL 获取一个文件这一事实并不排除在 20 个服务器/缓存上存在该文件的 20 个副本，其中一些可能已过时。
在这种情况下这是确定的，因为该网站似乎正在使用 Cloudfront，它是一个内容交付网络——一种明确设计用于在许多分布式服务器上缓存文件以在全球范围内交付的基础设施。
上述参考文件的作者在这里。
当修改构建脚本并自动触发并上传新构建时，当前状态下的所述文件的校验和是正常的。在 curl 7.46.0 的情况下，构建脚本（以及因此可下载的包）在撰写本文时更改了 3 次：
libcurl.dll构建错误，该错误是由缺少 nghttp2 构建选项引起的：提交、日志.vbs通过删除以前从原始 curl 源包中复制的可选文件来修复 VirusTotal 误报： commit , log此处的任何提交（对master分支进行）都将触发新的构建：
[ci skip]至于通过不同协议下载二进制文件，HTTP 与 HTTPS 应该产生完全相同的二进制内容（如果下载是在同一时间点进行的）——尽管强烈建议使用 HTTPS。
至于潜在的恶意软件，请参阅我在 GitHub 上的想法： https ://github.com/bagder/curl/issues/583#issuecomment-167520488
简而言之：它们几乎肯定是误报，不太可能受到传输协议的影响，更有可能受到扫描引擎问题的影响。完整的构建过程是公开的和可审计的，以及内置的所有源代码。）
更新 [2015-12-28]：作为对 HTTP 与 HTTPS 问题的一般回答：后者，安全协议确保内容来自正确的一方，并且在到达另一端的过程中不会被篡改电线。由于这些原因，它可以得到更多的信任，因此我在原始答案中推荐它。更好的保证是验证下载内容的 SHA256 哈希值与构建服务器本身生成的哈希值（在上面链接的构建日志的末尾可见）。更强有力的保证是对内容进行数字签名（fe 使用 PGP 或 minisign），并且该签名由接收者验证。（我的 curl 下载目前没有数字签名。）
更新 [2016-01-06]：更新了软件包更新列表。修复 VirusTotal 误报就是其中之一。
查看扫描上的时间戳，“干净”版本是几周前的。当您单击更新扫描日期的链接时，您会看到 http 和 https 都被感染。
基本上文件没有区别，只是扫描在两个不同的时间运行（感染前和感染后）
使用 HTTP 和 HTTPS 提供不同的文件实际上是例行公事。例如，假设您是一家银行。如果有人给出网址http://www.bank.com，银行不想使用 HTTP 也不想打扰你，所以它只是发出一个 301 或 302 重定向到https 的答案：/ /www.bank.com。这是尽可能透明的。