JavaScript文件进Memory Cache还是Disk Cache由浏览器自动决定：体积小于100KB更倾向内存缓存，超几百KB多入磁盘缓存；高频复用（如SPA路由切换）促进内存驻留；内存缓存随标签页关闭清除，磁盘缓存持久化保存。
体积大小直接影响缓存去向
小文件倾向留在内存里——一般 小于 100KB 的 JS 脚本更大概率进入 Memory Cache；超过几百 KB 的，浏览器通常直接写入 Disk Cache。这不是硬性阈值，但体积是首要参考因素。比如一个 28KB 的工具函数库（如 lodash-es 的子集），刷新后常显示 200 OK (from memory cache)；而一个打包后 450KB 的 vendor.js，基本固定走 from disk cache。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
使用频率决定是否长期驻留内存
Memory Cache 不只看大小，还看“是不是常用”。SPA 应用中频繁触发 history.pushState 或路由切换时，即使 JS 文件略大（比如 150KB），只要它被反复执行或解析，浏览器会优先保留在内存中供快速复用。反之，首次加载后就不再调用的脚本，哪怕很小，也可能很快被 LRU 算法淘汰。
- 首屏 JS（如入口文件）容易进 Memory Cache，尤其配合模块动态导入（
import()）时 - 按需加载的 chunk，若只用一次，可能刚加载完就被移出内存，下次就得从磁盘读
生命周期差异一目了然
打开 DevTools → Network 标签页，刷新页面，观察 JS 请求的 Size 列：
– 显示 (memory cache)：说明该 JS 正在当前标签页的内存中，关掉这个标签页就没了；
– 显示 (disk cache)：说明它被持久化到硬盘，重启浏览器甚至重启电脑后仍可能复用。
注意：两者都属于强缓存，不发请求，状态码都是 200，区别只在来源。
- Memory Cache 没有 HTTP 缓存头依赖，即使响应头没设
Cache-Control，只要资源已加载过，就可能暂存内存 - Disk Cache 受
Cache-Control、Expires控制，过期后会重新发起条件请求（协商缓存）
怎么验证当前 JS 走的是哪一种？
最直接的方法：
1. 打开 Chrome / Edge DevTools → Network 面板
2. 勾选 “Disable cache” 刷新一次（确保冷启动）
3. 取消勾选，再刷新 —— 查看 JS 请求的 Size 列文字
4. 若为 (memory cache)，右键该请求 → “Open in Sources”，能看到源码已解析并可断点调试；
若为 (disk cache)，打开后通常只显示原始文本，且首次解析耗时略高。
- 别依赖 “Size” 列的字面意思：有时显示 “(memory cache)” 却对应较大体积，这是因该资源刚被重用，尚未被 LRU 清理
- 同一份 JS，在不同标签页中可能分别走 memory 或 disk —— 内存分配是进程级的，非全局共享
