如图显示类似的警告信息，虽然不是错误，但这种还是很让人怀疑是不是哪里错了。有强迫症的来说，是受不了的。
查了一些资料，发现有解决方法，但是英文的如下：
Mixed Content is the delivery of resources (images, styles, scripts) from a site that is communicating over HTTPS over HTTP. Until now, you have only received a warning, but according to Google’s announcement, Googlebot will no longer read such mixed content. When I usually visit various sites, I often see sites that have not been successfully converted to https. Perhaps many people are unaware that their sites are causing mixed content, or they do not know what to do about it. This article is about how to find, fix, and correct mixed content.Add this Content-Security-Policy code in ‘meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"’ The important thing to remember is that CSP is there to restrict Web site content, not to loosen browser restrictions. Content-Security-Policy(CSP) is an HTTP specification to prevent Cross Site Scripting (XSS) and data injection attacks. A “mixed content” error occurs when a page communicating over secure HTTPS contains resources that should be loaded over insecure HTTP. Using the Content-Security-Policy: upgrade-insecure-requests mechanism, it is possible to force a page to be loaded with HTTPS even if mixed content is present. In other words, mixed content errors can be avoided. upgrade-insecure-requests is a new specification. If you set upgrade-insecure-requests in either the HTTP header or meta tag, the browser will try to load the HTTP content on the HTTPS page in HTTPS. If that content is not available in HTTP, it will be loaded in HTTP as usual (resulting in mixed content errors, of course). .htaccess Header add Content-Security-Policy "upgrade-insecure-requests" header('Content-Security-Policy: upgrade-insecure-requests'); To indicate whether the server side is supported, the following header should be sent from the server Content-Security-Policy: upgrade-insecure-requests To determine if the request is from a supported client, the following request header is used. Upgrade-Insecure-Requests: 1 However, upgrade-insecure-requests has a major drawback. The browser will just upgrade all URIs to https: // without regard to whether the resulting URI actually works on the page, which can break the page. If this problem occurs, it is better to manually change each link to https as shown below. Rewrite the URL so that the content of HTTP delivery is not included in the HTTPS delivery page. Specifically, add “s” to “http://” in the URL of the target content and change it to “https://”. This is generally described as eliminating Mixed Content. In order to deliver the entire blog with HTTPS, bloggers are required to resolve Mixed Content. Contents uploaded to Livedoor Blog support HTTPS delivery, but some contents loaded from other companies do not support HTTPS delivery. Please check the information of the provider to see if the content supports HTTPS delivery.
上面英文中主要的内容，及解决方案是这样的：
<最简单的方法>
在
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">要记住的重要一点是，CSP用于限制网站内容，而不是放松浏览器限制。
Content-Security-Policy (CSP) 是一种 HTTP 规范，用于防止跨站点脚本 (XSS) 和数据注入攻击。
当通过安全 HTTPS 通信的页面包含应通过不安全 HTTP 加载的资源时，会发生“混合内容”错误。
使用 Content-Security-Policy: upgrade-insecure-requests机制，即使存在混合内容，也可以强制使用 HTTPS 加载页面。
换言之，可以避免混合内容错误。
upgrade-insecure-requests是一个新规范。
如果您在 HTTP 标头或元标记中设置 upgrade-insecure-requests，浏览器将尝试在 HTTPS 中加载 HTTPS 页面上的 HTTP 内容。
如果该内容在 HTTP 中不可用，它将照常在 HTTP 中加载（当然会导致混合内容错误）。
.htaccess
标头添加 Content-Security-Policy "upgrade-insecure-requests"
php代码：
header('Content-Security-Policy: upgrade-insecure-requests');为了表明是否支持服务器端，应从服务器发送以下标头
内容安全策略：升级不安全请求
要确定请求是否来自受支持的客户端，请使用以下请求标头。
升级不安全请求：1
<升级不安全请求的一大缺点>
但是，升级不安全请求有一个主要缺点。浏览器只会将所有 URI 升级为 https:// 而不考虑生成的 URI 是否真的在页面上工作，这可能会破坏页面。
如果出现此问题，最好手动将每个链接更改为https，如下所示。
<手动转换为 https>
重写 URL，使 HTTP 传递的内容不包含在 HTTPS 传递页面中。
具体来说，就是在目标内容的URL中，在“http://”后面加上“s”，改成“https://”。
这通常被描述为消除混合内容。
为了使用 HTTPS 交付整个博客，博主需要解析混合内容。
上传到Livedoor Blog的内容支持HTTPS传送，但从其他公司加载的部分内容不支持HTTPS传送。请检查提供者的信息以查看内容是否支持 HTTPS 传送。
