浏览器根据资源体积、内存状态和加载上下文自动决策JS存放位置：小体积（如<100KB）、高频复用的JS倾向存入memory cache，读取极快但标签页关闭即失效；大体积JS则优先落盘至disk cache，受HTTP缓存头控制，持久性强。
浏览器把 JS 文件存进 memory cache 还是 disk cache，不是开发者手动指定的，而是由浏览器根据资源特性、内存状态和加载上下文自动决策的。关键不在于“JS 该不该缓存”，而在于“当前这个 JS 在此时此地，更适合放哪”。
Memory Cache 的特点与适用场景
内存缓存是浏览器把资源直接存在 RAM 里，读取极快，但生命周期短——只要标签页关闭、进程退出，就全清空。它适合存放体积小、复用率高、解析后能直接执行的资源。
- 刚下载并解析完的 JS 脚本（尤其是模块化入口、立即执行函数）常被保留在内存中，下次同页面内跳转或重复执行时可直接调用，不用重新 parse
- 字体、SVG 图标、小尺寸 base64 图片等轻量资源也容易进 memory cache
- 它不依赖 HTTP 缓存头（如 Cache-Control），纯由浏览器内部策略控制，开发者无法直接干预
Disk Cache 的特点与适用场景
硬盘缓存把资源写入本地磁盘文件，速度比内存慢，但持久性强——关掉浏览器再打开，只要没过期，依然可用。它更倾向存储体积较大、非即时执行、需长期复用的资源。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 打包后的 vendor.js、大型框架（如 React、Vue 的 UMD 版本）通常优先落盘，因为体积大，占内存不划算
- CSS 文件、图片、字体文件多数默认走 disk cache，尤其当响应头明确设置了 Cache-Control: public, max-age=31536000 时
- 它的存取受 HTTP 缓存策略主导：Expires、ETag、Last-Modified 都直接影响是否写入、何时失效
浏览器怎么决定 JS 放哪？核心逻辑是“大小 + 上下文 + 内存余量”
浏览器不会只看文件类型做判断，而是综合多个实时信号动态分配：
- 资源体积：小于 ~100KB 的 JS 更可能进 memory cache；超过几百 KB 基本直落 disk cache
- 加载时机：首次导航加载的 JS，若后续有频繁的 history.pushState 或 SPA 路由切换，浏览器倾向保留在内存中供快速重用
- 内存压力：设备空闲内存充足时，浏览器会更“大方”地缓存；内存紧张时，即使小 JS 也可能被踢出 memory cache，仅保留 disk cache 副本
- 复用信号：同一 JS 被多个 iframe 或 Worker 共享时，浏览器更可能保留在内存中，避免重复解析
实际观察与验证方法
打开 Chrome DevTools → Network 面板，刷新页面，看 JS 请求的 Size 列：
- 显示 from memory cache：说明这次是从当前进程内存中秒取的，没走磁盘也没发请求
- 显示 from disk cache：说明从本地磁盘读取，跳过了网络请求，但有 I/O 开销
- 显示具体字节数（如 245 B）：表示这次真发了请求，没命中任何缓存
注意：同一个 JS 文件，在不同访问场景下可能有时 from memory，有时 from disk —— 这恰恰说明浏览器在动态权衡，不是固定规则。
