安全上下文是浏览器判定页面是否处于可信环境的核心机制，仅当页面通过HTTPS或localhost等豁免地址加载时生效，决定Geolocation、带凭据CORS等敏感API能否调用；HTTP页面因不满足安全上下文而被限制跨域凭据传递及混合内容请求。
安全上下文（Secure Context）是浏览器判断页面是否处于可信环境的核心依据，它直接影响跨域行为的执行权限，尤其是对 CORS 的实际效果有硬性约束。
什么是安全上下文
一个页面属于安全上下文，当且仅当它通过 HTTPS 协议加载，或运行在本地开发环境（localhost、127.0.0.1）等被浏览器明确豁免的地址上。HTTP 页面默认不属于安全上下文。
浏览器会通过 window.isSecureContext 属性暴露该状态，返回 true 或 false。很多现代 Web API（如 Geolocation、WebUSB、Credential Management、以及部分 CORS 行为）仅在安全上下文中可用。
安全上下文如何限制跨域能力
即使后端已正确配置 CORS 响应头，若当前页面不在安全上下文中，某些跨域操作仍会被浏览器主动拒绝：
立即学习“Java免费学习笔记（深入）”；
- 带凭据（
credentials: 'include'）的跨域请求，在 HTTP 页面中会被直接拦截，控制台提示类似 “A cookie associated with a cross-site resource was set without theSameSiteattribute” 或 “Failed to execute 'fetch' on 'Window': Request mode is 'cors' but credentials flag is 'true'” -
Access-Control-Allow-Credentials: true的响应头，在非安全上下文中可能被忽略，导致凭据（如 Cookie、HTTP 认证）无法发送或接收 - 使用
fetch请求https://接口时，若当前页面是http://，部分浏览器（如 Chrome）会直接阻止请求发起，并报错 “Mixed Content” —— 这不是 CORS 错误，而是混合内容拦截，发生在网络层而非 CORS 检查阶段 - 某些高权限响应头（如
Access-Control-Expose-Headers中指定的敏感头）在非安全上下文中可能不生效，JS 无法读取
常见场景与应对建议
开发和部署中需特别注意以下几点：
- 本地开发用
http://localhost:3000是安全上下文，CORS 凭据请求通常正常；但换成http://192.168.x.x:3000就不是，此时需启用 HTTPS 或改用localhost - 测试环境务必使用 HTTPS，哪怕自签名证书（配合浏览器信任），否则
credentials: true类请求必然失败 - 避免在 HTTP 页面中尝试调用需要凭据的第三方 API（如登录态校验接口），浏览器会静默拒绝或抛出不可捕获的 TypeError
- 检查
isSecureContext状态再发起敏感请求，例如：
if (!window.isSecureContext) { console.warn('当前非安全上下文，禁止发起带凭据的跨域请求'); return; }
与同源策略的关系
同源策略本身不依赖安全上下文，它始终生效；但安全上下文是浏览器施加的**额外准入门槛**，用于收紧高风险能力的使用条件。可以理解为：同源策略划出“能不能交互”的边界，而安全上下文决定“有没有资格启用这些交互中的高危选项”。
CORS 是同源策略的例外机制，但它不是万能通行证——它必须运行在浏览器认可的可信环境中，才能完整兑现其授权能力。
