修复混合内容错误需先确认目标是否支持HTTPS，再选择硬写https://、协议相对URL//或CSP升级；用Chrome DevTools的Console、Security和Network标签页定位HTTP资源，避免无脑全局替换导致404或证书错误。
直接换掉所有 http:// 不一定安全，甚至可能让资源 404 或证书错误——先确认目标是否真支持 HTTPS，再决定是硬写 https://、用协议相对 URL //，还是走代理或 CSP 升级。
怎么快速定位页面里哪些地方写了 http://
别只刷一次控制台就收工。很多混合内容是 JS 动态插入的，比如富文本里的图片、懒加载组件、第三方统计脚本初始化时自己拉的资源。
- 打开 Chrome DevTools → Console 标签页，直接看红色报错行，例如：
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.net/script.js'. - 切到 Security 标签页 → 点开 “Mixed Content”，它会列出所有被拦截的 URL 和对应 HTML 行号
- 在 Network 标签页勾选
Preserve log，然后滚动、点击、触发交互，再筛选Initiator是script或other的请求，找状态为failed且提示blocked:mixed-content的条目 - 控制台执行这句也能快速扫一遍静态 HTML：
document.querySelectorAll('script[src^="http://"], link[href^="http://"], img[src^="http://"], iframe[src^="http://"]')
http:// 能不能直接全局替换成 https://
不能无脑替换。目标域名没配 HTTPS 或证书无效，换完就是 net::ERR_CERT_INVALID 或 ERR_CONNECTION_REFUSED，比原来还糟。
- 先手动访问
https://+ 那个域名（比如https://cdn.example.com/logo.png），看能不能正常加载、证书是否有效 - 确认支持 HTTPS 的，才批量把
http://换成https://；不支持的，要么推动对方升级，要么换 CDN 或子域（比如用https://static.yoursite.com） - 后端模板里别拼字符串：
"http://" + domain + "/api"，改用框架的安全函数，比如 Django 的request.build_absolute_uri()，或 Laravel 的secure_url() - 第三方 SDK（如旧版百度统计、微信 JS-SDK）必须查最新文档，
http://bdimg.share.baidu.com/这类地址已不可用
协议相对 URL // 为什么有时反而更危险
//cdn.example.com/js/app.js 看起来省事，但它把风险转嫁给了目标服务——它必须同时支持 HTTP 和 HTTPS，且两者配置一致。
- 本地开发用
file://打开 HTML 文件时，//会变成file://cdn.example.com/...，直接失败 - 某些老版本 Safari 对
//解析异常，尤其用在iframe的src上 - 如果 CDN 只开了 HTTPS，但没关 HTTP 端口或没配重定向，HTTPS 页面下
//仍会尝试走 HTTP，结果被浏览器拦截 -
//对javascript:、data:这类伪协议无效，也不能解决 JS 里动态拼接的"http://" + url
Content-Security-Policy: upgrade-insecure-requests 能不能当万能补丁
不能。它只对浏览器解析 HTML 时发起的初始请求生效，对 DOM 已存在的 src/href 属性、JS 动态设置的 URL、重定向链中的中间跳转，统统无效。
- Apache 加这行：
Header set Content-Security-Policy "upgrade-insecure-requests" - Nginx 加这行：
add_header Content-Security-Policy "upgrade-insecure-requests"; - 它对
<img src="http://...">有效，但对document.getElementById("x").src = "http://...";无效 - Safari 直到 11.1 才支持，IE 完全不支持；Chrome 55+、Firefox 48+ 可用
- 即使开了这个头，也得确保目标 HTTPS 地址真能响应，否则请求只是从“被拦截”变成“连接失败”
最麻烦的其实是那些你控制不了的第三方脚本——它们硬编码了 http:// 地址，又没法改源码。这时候要么联系对方提供 HTTPS 版本，要么用反向代理把 HTTP 请求兜底转成 HTTPS，或者用 Puppeteer 全站扫描 + 自定义白名单做自动化修复。真正的难点不在技术，而在协调和验证：每个链接都得有人确认它背后的服务是否真的 ready。
