第三方脚本缓存由其服务端响应头（如cache-control）决定，html或本地配置无法干预；强制更新唯一有效方式是变更url，如使用带版本号的路径。
第三方脚本的缓存行为由其响应头决定，不是你页面能直接控制的
你在 <script src="https://cdn.example.com/lib.js"></script> 里引用一个第三方脚本，它的缓存策略完全取决于那个 CDN 或服务器返回的 HTTP 响应头（比如 Cache-Control、Expires），而不是你自己的 HTML 或 webpack 配置。哪怕你本地设了 no-cache，对它也没用。
常见情况是：CDN 通常会设置较长的 max-age（比如 1 年），所以用户第一次加载后，后续几天甚至几周内都会走本地磁盘缓存——你更新了自己页面，但用户看到的仍是旧版第三方脚本。
- 如果第三方脚本返回
Cache-Control: public, max-age=31536000，浏览器会缓存一年，期间所有请求都从磁盘读，不发网络请求 - 如果返回
Cache-Control: no-store，则完全不缓存，每次都是全新请求（极少见） - 若返回
ETag或Last-Modified，且缓存未过期，浏览器会发带If-None-Match的条件请求，服务端返回304 Not Modified，仍走缓存
想强制更新第三方脚本？只能改 URL，别指望清自己缓存
你清空自己浏览器的缓存、关掉 Disable cache、甚至重装浏览器，对已缓存的第三方脚本都没用——只要它的 URL 没变，且响应头允许缓存，浏览器就认它是同一个资源。
真正有效的做法只有一种：让 URL 变化。这不是“加个时间戳”这种随意操作，而是要依赖第三方是否提供版本化入口：
- 优先使用带明确版本号的 URL，例如
https://unpkg.com/react@18.2.0/umd/react.production.min.js，而不是https://unpkg.com/react/umd/react.production.min.js（后者可能指向最新版，缓存策略也更激进） - 有些 CDN 支持
?v=或?t=参数，但注意：只有当服务端不忽略查询参数时才生效；很多静态 CDN 会把lib.js?v=2和lib.js?v=3当作同一文件处理（因为实际文件没变） - 绝对不要用
?t=<time></time>这类动态时间戳——它会让每次请求都变成新 URL，彻底废掉缓存价值，还可能触发 CDN 频繁回源
第三方脚本缓存引发的典型问题
这类缓存最常在灰度发布或紧急回滚时暴露问题：你已在服务端切掉了某个埋点 SDK 的新版本，但大量用户仍在运行缓存里的旧版，继续上报错误数据；或者你修复了一个兼容性 bug，但用户侧因缓存没更新，依然白屏。
更隐蔽的是调试困难：你在 Network 面板看到某第三方 JS 请求状态是 200 (from disk cache)，点开 Response 空空如也——因为磁盘缓存不存原始响应体，只存字节流，开发者工具无法展示内容。
- 遇到疑似第三方脚本行为异常，先看 Network 里它的响应头，重点关注
Cache-Control和Age字段 - 想确认是否真在跑缓存版本？打开无痕窗口访问，或用
curl -I https://xxx/lib.js对比响应头和你本地看到的是否一致 - 如果你是第三方服务提供方，务必避免在长期缓存资源上做“热更新”——改了代码却不改 URL，等于让用户持续运行带 bug 的旧逻辑
Service Worker 也无法绕过第三方脚本的底层缓存规则
有人试图用 Service Worker 的 fetch 事件劫持第三方脚本请求，然后手动加 cache-bust 参数重发。这看似可行，但存在两个硬伤：
- 多数主流第三方 CDN（如 unpkg、jsDelivr）会返回
Vary: Origin或Vary: Accept-Encoding，而 Service Worker 缓存不自动处理Vary，导致缓存错乱 - 如果第三方脚本本身设置了
Cache-Control: immutable，现代浏览器会彻底禁止你通过 JS 修改其缓存行为（包括 SW 的fetch返回也不被信任） - 更现实的问题：你无法控制第三方脚本内部是否调用
importScripts()或动态document.write()，这些行为在 SW 环境下可能直接失败
真正可控的边界只有一个：URL 是否可预测、是否带版本、响应头是否合理。其它所有“绕过”尝试，最终都会撞在浏览器缓存栈的底层规则上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
