JavaScript 无法直接控制磁盘缓存写入，其由浏览器根据 HTTP 响应头（如 Cache-Control: public, max-age）、稳定 URL（推荐哈希命名）、标准标签加载方式及资源大小等因素自动决策，小资源倾向内存缓存，大资源更易进入磁盘缓存。
JavaScript 本身不直接控制磁盘缓存（disk cache）的写入行为。disk cache 是浏览器底层网络层和渲染引擎（如 Blink、WebKit）自动管理的机制，由 HTTP 响应头、资源类型、请求方式、用户行为等共同决定，JavaScript 无法通过代码主动“触发”或“强制”将某资源存入磁盘缓存。
但你可以通过合理配置服务端响应和前端资源加载方式，引导浏览器在合适条件下将资源存入 disk cache。关键在于让浏览器判定该资源“适合长期缓存且可复用”。
以下是实际起作用的要点：
✅ 正确设置 HTTP 缓存响应头
浏览器是否将资源存入 disk cache（而非仅 memory cache），主要取决于响应头中的缓存策略：
立即学习“Java免费学习笔记（深入）”；
-
Cache-Control: public, max-age=31536000
→ 表明资源可被所有中间代理和浏览器缓存，有效期 1 年，大概率走 disk cache（尤其对.js、.css、.woff2等静态资源）。 -
Cache-Control: immutable（配合max-age）
→ 明确告诉浏览器该资源内容不会变（如带哈希的文件名main.a1b2c3.js），可放心存入 disk cache 并跳过后续条件请求。 - 避免
Cache-Control: no-store或no-cache（后者虽允许缓存，但每次都会发条件请求，通常不落盘）。
注意：
Expires头已逐渐被Cache-Control取代；若两者共存，Cache-Control优先。
✅ 使用稳定、唯一的资源 URL
浏览器以 URL 为缓存键。若 URL 不变且响应头允许缓存，相同 URL 的后续请求就可能命中 disk cache：
- ✅ 推荐：
/static/js/app.2f8a1d.js（内容哈希命名） - ❌ 避免：
/static/js/app.js?v=1.2.3（查询参数易被 CDN 或代理忽略，且v=变更时旧缓存失效不可控）
✅ 通过 <script>、<link> 等标准方式加载资源
浏览器对以下方式的资源更倾向启用 disk cache：
<script src="/a.js"></script><link rel="stylesheet" href="/b.css"><img src="/c.png">
而通过 fetch() 或 XMLHttpRequest 加载的资源，默认受 Cache-Control 控制，但是否落盘还取决于请求模式：
-
fetch('/data.json')→ 默认cache: 'default'，遵循响应头，可能进 disk cache； -
fetch('/data.json', { cache: 'no-store' })→ 强制不缓存； -
fetch('/data.json', { cache: 'force-cache' })→ 忽略响应头，强制用缓存（但仍依赖此前是否已存入 disk cache）。
✅ 用户行为与浏览器策略也会影响
- 首次加载后，若资源满足缓存条件，Chrome 通常会在 DevTools → Application → Cache Storage 查不到（那是 Service Worker 的 cache），但在 DevTools → Network → Size 列显示
(disk cache)即表示命中； - 小资源（如小于 10KB 的 JS）有时只进 memory cache；大资源（如 >100KB 的 JS/CSS）更倾向写入 disk cache；
- 隐私模式、无痕窗口、禁用缓存开发者选项（Network 面板勾选 “Disable cache”）会绕过 disk cache。
不复杂但容易忽略
