HTTPS页面加载HTTP资源会被浏览器强制拦截，需通过开发者工具Network面板筛选http://定位问题，修复方式包括CSP头、协议相对URL或JS动态拼接HTTPS地址。
HTTPS 页面里加载 HTTP 资源，浏览器直接阻止——这不是 bug，是现代浏览器的强制安全策略。主动混合内容（如 <script></script>、<iframe></iframe>、fetch()）一律拦截，被动混合内容（如 <img alt="HTML HTTPS不支持混合内容怎么办_HTML HTTPS适配混合内容策略【攻略】" >）多数浏览器也已默认屏蔽。硬刷新或清缓存解决不了，必须改资源协议或加载方式。
怎么快速定位所有 HTTP 资源
别靠肉眼翻 HTML 源码，效率低还容易漏。打开 Chrome 或 Edge 的开发者工具（F12），切到 Network 标签页，刷新页面后在 Filter 输入框里直接填 http:// ——所有未升级的请求会立刻高亮。再点开每个请求的 Headers，看 Request URL 确认协议；如果控制台有报错，典型格式是：Mixed Content: The page at 'https://xxx' was loaded over HTTPS, but requested an insecure script 'http://cdn.xxx.com/xxx.js'，错误信息里已经把问题资源地址写全了。
三种修复方式的实际效果和限制
不是所有方案都“一加就灵”，得看场景和兼容性：
-
upgrade-insecure-requestsCSP 响应头（服务端配置）：Nginx 加add_header Content-Security-Policy "upgrade-insecure-requests";，Apache 加Header set Content-Security-Policy "upgrade-insecure-requests"。但它只对支持该指令的浏览器生效（Chrome 43+、Firefox 42+），且对document.write()注入或早期动态拼接的http://字符串无效。 -
<meta>标签等效写法：<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">。仅作用于当前页面，无法继承，也不适用于 iframe 子页面，且部分旧版 Safari 不识别。 - 协议相对 URL（
//cdn.example.com/script.js）：简单有效，但要求目标域名同时支持 HTTP 和 HTTPS。如果 CDN 已停用 HTTP（比如某些免费图床强制 HTTPS），访问会失败，且无法用于fetch()或XMLHttpRequest的 URL 参数中（会解析为相对路径）。
JavaScript 动态加载 HTTP 资源时的坑
很多老项目把接口地址或脚本路径写死在 JS 里，比如：
立即学习“前端免费学习笔记（深入）”；
const url = 'http://api.example.com/data'; fetch(url);
这种写法在 HTTPS 页面下必然触发 block:mixed-content。不能只改 HTML，JS 里的字符串也得动：
- 显式写成
https://（推荐）：确保后端真支持 HTTPS，否则请求 404。 - 用
window.location.protocol拼接：const url = window.location.protocol + '//api.example.com/data';，但注意它返回的是https:（带冒号），别漏掉。 - 避免用
document.write()插入含http://的<script></script>，这个行为在现代浏览器中已被 CSP 严格限制，且无法被upgrade-insecure-requests覆盖。
IFRAME 和 API 请求必须单独处理
<iframe src="http://xxx"></iframe> 和 fetch('http://xxx') 是最典型的主动混合内容，浏览器拦截无商量余地。它们不走 CSP 升级逻辑（除非服务端明确配了 upgrade-insecure-requests 且浏览器支持），也不能用协议相对 URL 替代（src="//xxx" 对 iframe 有效，但 fetch("//xxx") 会报错）。唯一稳妥路径是：后端接口必须上 HTTPS，前端 URL 字符串必须写死 https:// 或由后端透传真实 HTTPS 地址。临时用 Nginx 反向代理转发 HTTP 接口到 HTTPS 域名下，只是过渡手段，不能替代证书部署。
