HTTPS是现代网页运行的强制前提，因浏览器将HTTP视为不安全上下文，导致fetch跨域拒绝、Geolocation报错、Service Worker无法注册、混合内容被拦截、HTTP/2与HTTP/3无法启用等核心功能失效。
HTTPS 不是可选的“增强项”，而是现代 HTML 页面能被浏览器正常加载、不被拦截、不被警告的前提。没有 HTTPS，fetch() 会拒绝跨域请求，localStorage 在部分浏览器中受限，Geolocation 和 MediaDevices.getUserMedia() 等 API 直接报错或静默失败。
为什么 Chrome/Firefox 会阻止 HTTP 页面里的敏感 API
浏览器将 HTTP 视为“不安全上下文”（insecure context），而很多新 API 明确要求运行在安全上下文中。这不是 bug，是 W3C 标准强制行为。
-
Geolocation在 HTTP 页面中返回NotAllowedError，即使用户点了“允许”也无效 -
Service Worker注册必须通过 HTTPS（本地localhost是唯一例外） -
Web Crypto API的某些方法（如subtle.importKey()）在非安全上下文中抛出SecurityError - Chrome 120+ 对 HTTP 页面的
document.cookie默认添加Secure标志，导致 Cookie 实际不发送
HTTP 页面里嵌入 HTTPS 资源仍会触发混合内容警告
即使你手动把图片、脚本、CSS 改成 https://，只要页面本身是 http://，浏览器仍会标记为“混合内容”（mixed content），并默认阻止主动型资源（如 JS、iframe）加载。
- 浏览器控制台报错：
Mixed Content: The page at 'http://example.com/' was loaded over HTTP, but requested an insecure script 'http://cdn.example.net/script.js'. This request has been blocked - Chrome 会直接屏蔽
<script src="http://..."></script>，且不提供“允许不安全脚本”的手动开关（自 Chrome 95 起） - 用
Content-Security-Policy无法绕过该限制——这是网络层拦截，不是策略层过滤
HTML 中相对协议 URL（//example.com）已失效
过去常用 src="//cdn.example.com/jquery.js" 让资源自动适配页面协议，但这在现代开发中反而危险：
- 如果页面因重定向或缓存意外降级为 HTTP，该资源就变成明文加载，触发混合内容阻断
- CDN 返回 301 到 HTTP 地址时，整个链路退化为不安全上下文
- 现代构建工具（如 Vite、Webpack）默认不再支持这种写法；Lighthouse 审计会将其标为“潜在不安全资源”
- 正确做法是硬编码
https://，并确保所有后端响应头含Strict-Transport-Security
HTTPS 不是“加个证书就完事”，关键在 HSTS 和证书链完整性
只配置 ssl_certificate 和 ssl_certificate_key 远不够。常见漏配导致页面仍被标记为不安全：
- 缺失中间证书：浏览器无法验证证书链，Safari 和 Firefox 可能直接拒绝连接，错误信息为
SSL_ERROR_BAD_CERT_DOMAIN或NET::ERR_CERT_AUTHORITY_INVALID - 未启用 HSTS：用户首次访问仍可能走 HTTP，给中间人攻击留窗口；应设置
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - 证书域名不匹配：比如用
www.example.com证书服务api.example.com，浏览器报NET::ERR_CERT_COMMON_NAME_INVALID - 使用自签名或过期证书：本地开发可用，但任何真实用户环境都会触发全屏警告，且无法忽略
最易被忽略的一点：HTTP/2 和 HTTP/3 协议强制要求 TLS，哪怕你只想要更快的资源加载速度，也必须先搞定 HTTPS 配置和证书链验证——没有折中路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
