浏览器缓存策略决定javascript脚本是否重复加载，从而影响执行次数；强缓存或协商缓存下脚本只执行一次，缓存失效则导致重复初始化、事件重复绑定等异常。
浏览器缓存策略会直接影响 JavaScript 脚本的加载时机和执行次数，但不会改变脚本本身的执行逻辑或频率（如 setInterval、事件触发等）。真正影响“执行频率”的，是脚本是否被重复加载——而缓存决定它是否从网络重新拉取、是否复用已加载的副本。
缓存控制决定脚本是否重新下载
当 HTML 中通过 <script src="app.js"></script> 引入外部脚本时，浏览器依据 HTTP 响应头（如 Cache-Control、Expires、ETag）判断是否复用本地缓存：
- 若命中强缓存（如
Cache-Control: max-age=3600），浏览器直接执行缓存版本，不发请求 → 脚本只执行一次（刷新页面也无新请求） - 若走协商缓存（如带
ETag或Last-Modified），服务器返回304 Not Modified→ 复用缓存脚本，仍只执行一次 - 若缓存失效或被禁用（如
Cache-Control: no-cache或开发者工具勾选 “Disable cache”），每次刷新都重新下载并执行 → 可能导致重复初始化、重复绑定事件、重复创建全局变量
执行频率异常的常见表现
看似“执行频率变高”，往往源于缓存未生效导致脚本被多次加载执行，而非浏览器主动反复调用代码：
-
重复绑定事件监听器：每次加载都执行
btn.addEventListener('click', handler)，结果一次点击触发多次 handler -
全局变量/函数被重复声明：缓存失效时，
var myModule = {...}在每次加载中都执行，可能覆盖或报错（严格模式下重复let报错） - 副作用逻辑重复运行：如自动上报、初始化 SDK、修改 DOM 结构等，在每次脚本加载时都再跑一遍
如何确保脚本按预期执行一次
关键不是禁止缓存，而是让缓存可控、让执行逻辑可重入：
- 为静态 JS 设置合理缓存（如
Cache-Control: public, max-age=31536000），配合文件内容哈希命名（app.a1b2c3.js） - 避免在顶层作用域写有副作用的初始化代码；改用显式入口函数（如
initApp()），并在 HTML 中统一调用一次 - 使用模块化（ESM）+
export/import，天然支持单例语义；或用 IIFE + 标志位防止重复执行 - 开发阶段检查 Network 面板：确认脚本状态是
from disk cache或from memory cache，而非200（新响应）
动态加载脚本需额外注意缓存行为
通过 document.createElement('script') 或 import() 动态引入时，缓存策略同样生效，但容易被忽略：
-
import('./module.js')默认遵循 HTTP 缓存规则；若希望强制更新，可在 URL 后加时间戳或哈希参数（如./module.js?t=123） - 手动创建 script 标签时，设置
script.src = 'a.js?_=' + Date.now()会绕过缓存 → 每次都重新下载执行，慎用 - 多个模块相互 import，浏览器会去重；但同一 URL 多次
import()仍只执行一次模块代码（符合 ES 规范）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
