HTTPS页面中fetch('http://...')会被浏览器直接拦截，因混合内容安全策略强制阻止HTTP请求发出；需从前端代码入手，全局搜索fetch、Request、XMLHttpRequest等调用，检查硬编码或拼接的HTTP地址，并统一改为HTTPS协议。
HTTPS 页面里用 fetch('http://...') 会直接被浏览器拦截，请求根本不会发出，控制台报错但 Network 面板看不到记录——这不是 bug，是强制安全策略。定位和修复必须从前端代码入手，不能靠刷新或清缓存。
快速定位 fetch 中的 HTTP 地址
别只盯着 HTML，重点查 JS 文件里的硬编码和拼接逻辑：
- 全局搜索项目中所有
fetch(、new Request(、XMLHttpRequest，逐个检查参数字符串是否以http://开头 - 注意环境变量或配置对象里混入的 HTTP 地址，比如
const API_BASE = process.env.API_URL || 'http://localhost:3000' - 第三方 SDK（如老版统计、客服插件）内部发起的 fetch，需查阅其文档，确认是否支持 HTTPS 配置或自动升级
- 本地调试地址（
http://127.0.0.1、http://192.168.x.x）在生产环境必须替换，不能保留
修复 fetch 请求协议不一致的核心方法
显式写死 https:// 是唯一可靠方式，前提是后端已启用有效证书并支持 TLS 1.2+：
- 把
fetch('http://api.example.com/data')改成fetch('https://api.example.com/data') - 若接口尚未支持 HTTPS，不要用
//api.example.com替代——fetch 中的//会被解析为相对路径，导致 404 - 动态拼接 URL 时，确保 base 部分已是 HTTPS：
fetch(`${API_BASE}/user`)中的API_BASE必须含https:// - 使用构建工具（如 Webpack/Vite）时，可在环境变量中统一注入 HTTPS 域名，避免多处硬编码
绕过混合内容限制的常见误区
这些做法在当前环境下已失效或不可靠：
立即学习“Java免费学习笔记（深入）”；
-
协议相对 URL（//）不适用于 fetch：它只对 HTML 标签（script、link、img）生效，fetch 参数中写
//api.com会被当作相对路径处理 - CSP 头 upgrade-insecure-requests 对 fetch 无效：该策略仅作用于 HTML 解析阶段加载的资源，无法重写 JS 运行时构造的 URL 字符串
- 用 JS 动态替换 window.location.href 协议：无法改变已运行脚本中的字符串字面量，属于事后补救，不解决源头问题
- 依赖服务端跳转或 meta 刷新：混合内容拦截发生在前端网络层，请求从未发出，服务端无从干预
验证修复是否彻底
改完代码后，必须在真实 HTTPS 环境下验证：
- 打开 Chrome DevTools → Console 标签页，确认不再出现
Mixed Content红字报错 - 切换到 Network 标签页，勾选 Preserve log，刷新页面后在 Filter 框输入
http://，应无任何匹配项 - 特别检查富文本字段、CSS background、JS 动态创建的 Image 或 fetch 调用——这些常被忽略但同样触发拦截
- 如果仍报错，复制错误信息中的完整 URL，在项目中全局搜索，定位到具体 JS 文件与行号
