HTTPS页面加载HTTP资源会被现代浏览器默认阻止，主动混合内容（如script、iframe）直接报错阻断，被动内容（如img）在Chrome 94+也统一阻止；应将所有http://替换为https://，并检查API、第三方SDK及构建流程。
HTTPS 页面里加载 HTTP 资源会直接被浏览器阻止
现代浏览器（Chrome、Firefox、Edge）默认禁止 HTTPS 页面加载 HTTP 的 <script>、<iframe>、<img>、<audio>、<video> 等主动混合内容（mixed active content）。一旦出现，控制台立刻报错：Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure script 'http://...'.，且脚本/样式/框架根本不会执行或渲染。
被动混合内容（如 <img>）在部分浏览器中可能仅警告不阻断，但 Chrome 94+ 已统一升级为默认阻止——不能心存侥幸。
把所有 HTTP URL 改成协议相对或显式 HTTPS 是最稳妥解法
协议相对 URL（//example.com/js/app.js）曾是常见过渡方案，但它依赖目标服务器同时支持 HTTP 和 HTTPS，且在 file:// 协议下会失效；如今更推荐显式写死 https://。
实操建议：
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 搜索项目中所有
http://开头的资源链接（含内联src、href、CSS 中的url()、JS 动态拼接的 URL），批量替换成https:// - 后端 API 接口也要同步检查：如果前端 JS 用
fetch('http://api.example.com/v1')，必须改为fetch('https://api.example.com/v1') - 第三方 SDK（如百度统计、友盟、微信 JS-SDK）务必查阅其最新文档，确认是否提供 HTTPS 入口；旧版
http://bdimg.share.baidu.com/类地址已不可用
开发环境本地调试时 HTTP 资源不被拦？那是你没开严格模式
localhost 和 127.0.0.1 默认被浏览器豁免混合内容检查，所以本地 http://localhost:3000 加载 http://api.dev 看似正常。但这只是假象——一上真实 HTTPS 域名就立刻崩。
提前暴露问题的方法：
- Chrome 启动时加参数：
--unsafely-treat-insecure-origin-as-secure="http://api.dev" --user-data-dir=/tmp/chrome-test，让本地也按 HTTPS 规则校验 - 或在非 localhost 域名下测试：用
127.0.0.1.xip.io或mkcert生成本地 HTTPS 证书，强制走 HTTPS 流程 - CI 构建阶段加入检查脚本：用正则扫描 HTML/JS/CSS 文件，告警所有硬编码的
http://（排除注释和字符串字面量需谨慎）
Content-Security-Policy 的 upgrade-insecure-requests 不是万能补丁
这个响应头（Content-Security-Policy: upgrade-insecure-requests）会让浏览器自动把页面内所有 HTTP 请求升格为 HTTPS，听起来很美。但它有硬限制：
- 只对当前页面发起的请求生效（比如 HTML 里的
<script src="http://...">），对 JS 内部用XMLHttpRequest或fetch拼出的 HTTP 字符串无效 - 若目标域名没有 HTTPS 服务（如内网 HTTP-only 接口），升格后直接 404 或连接拒绝，错误更隐蔽
- 不解决资源跨域问题：HTTP → HTTPS 升级后仍可能因 CORS 被拒，得额外配
Access-Control-Allow-Origin
它适合快速修复大量静态资源引用，但不能替代逐项排查和改造。
真正难啃的是那些深埋在第三方库、老旧 CMS 模板、CDN 配置或运维脚本里的 HTTP 地址——它们往往不在你直接掌控的代码里，得靠日志、抓包、CSP 报告反向定位。
