全站启用 HTTPS 后静态资源外链加载失败，主因是混合内容拦截、缓存头配置不当或 CORS 缺失；需统一外链为 HTTPS、配置合理 Cache-Control 与 CORS 响应头，并多维度验证缓存命中。
全站启用 HTTPS 后，静态资源外链（如 CDN 上的 JS/CSS/图片）加载失败，通常不是缓存本身失效，而是协议、路径或安全策略在 HTTPS 上下文中被破坏。关键在于让外链资源“可访问”“可缓存”“不被拦截”，三者缺一不可。
确保外链资源使用 HTTPS 协议
浏览器对混合内容（HTTP 资源嵌入 HTTPS 页面）默认阻止加载，此时资源根本不会进入缓存流程。必须杜绝硬编码 http:// 的外链：
- 将所有外链改为显式 HTTPS：
https://cdn.example.com/app.js - 或使用协议相对 URL（仅限兼容旧场景）：
//cdn.example.com/app.js（注意：现代规范已不推荐，且在某些 WebView 中可能降级为 HTTP） - 在 Nginx 的响应头中加强制升级策略：
add_header Content-Security-Policy "upgrade-insecure-requests;" always;
浏览器会自动把页面中所有http://外链重写为https://
外链响应头需支持 HTTPS 缓存语义
即使链接是 HTTPS，若远端服务返回了禁止缓存的响应头（如 Cache-Control: no-store），浏览器仍不会缓存。你需要确认或协同 CDN 提供方配置合理头信息：
- 带哈希指纹的资源（
main.a1b2c3.js）：Cache-Control: public, immutable, max-age=31536000 - 常规静态文件（无指纹但变动少）：
Cache-Control: public, max-age=2592000（30 天） - 避免在 Nginx 全局或 server 块中用
add_header Cache-Control覆盖上游头；如需覆盖，限定在特定 location，并用always参数确保生效
处理跨域外链的缓存与 CORS 兼容性
CDN 或第三方静态资源常启用 CORS（如 Access-Control-Allow-Origin: *）。若未正确设置，浏览器可能拒绝读取响应体，导致缓存无法建立或 JS 执行失败：
- 确保外链响应中包含：
Access-Control-Allow-Origin: *（或具体域名）Access-Control-Allow-Methods: GETAccess-Control-Allow-Headers: *（如有必要） - 若资源用于
等非脚本上下文，CORS 非必需；但若通过fetch()或XMLHttpRequest加载，则必须满足 CORS 要求才能缓存并复用 - Nginx 代理外链时（如反代 CDN），需透传原始 CORS 头，不要覆盖或遗漏：
proxy_pass_request_headers on;proxy_hide_header Access-Control-Allow-Origin;← 不要加这行
验证缓存是否真正生效
不能只看 Network 面板的 Size 显示 “(memory cache)” 或 “(disk cache)”，要结合多维度确认：
- 用
curl -I https://cdn.example.com/app.js检查实际返回的Cache-Control、ETag、Last-Modified - 刷新页面后，在 Chrome DevTools → Network → 找该资源 → 查看
Size列是否为from disk cache或from memory cache - 观察
Timing标签页：若Waiting (TTFB)接近 0ms 且无 TLS 握手延迟，说明命中本地缓存；若 TTFB 较高但Content Download很快，可能是 CDN 边缘节点缓存命中
