需要先明确一点：HTTP 强缓存头并不是 Ja vaScript 能直接设的，这件事必须交给服务端来配置。

实践里通常优先用 Cache-Control。比如 public、max-age=31536000、immutable 这一类组合，再配合 Expires 做兜底，这样更稳妥。

至于前端，虽然不能直接下手改强缓存头，但可以通过文件哈希、Service Worker 等方式，从侧面把缓存效果进一步优化好。

Ja vaScript 其实并不能直接去配置 HTTP 强缓存头，比如 Cache-Control 或 Expires。

原因很简单：这类响应头必须由服务器在资源返回时写入。前端代码运行在浏览器里，只能消费响应，没权限改动服务器已经发出的 HTTP 响应头。

真正决定缓存是否生效的，归根到底还是服务端逻辑，或者 Web 服务器本身的配置。

服务端设置 Cache-Control（推荐方式）

现代 Web 应用应优先使用 Cache-Control。它比 Expires 更可靠，基于相对时间，不受客户端时钟偏差影响。

• 静态资源（JS/CSS/图片）：通常设为长期缓存，并配合文件内容哈希命名（如 app.a1b2c3.js），避免更新后用户仍加载旧版本。
• max-age=31536000 表示缓存 1 年（365 天 × 24 小时 × 3600 秒），适用于不变的第三方库或带哈希的构建产物。
• public 允许 CDN 和浏览器共同缓存；private 仅限用户浏览器缓存（如含用户数据的 HTML）。
• 示例（Node.js/Express）：

app.get('/static/js/bundle.js', (req, res) => {
res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
res.sendFile(path.join(__dirname, 'static/js/bundle.js'));
});

其中 immutable 是可选指令。它告诉浏览器，该资源在 max-age 期内绝不会变更，可跳过后续条件请求（如 If-None-Match）。

服务端设置 Expires（兼容旧环境）

Expires 是 HTTP/1.0 遗留字段，值为 GMT 格式绝对时间。

若与 Cache-Control 同时存在，后者优先。仅在需兼容极老客户端时考虑使用。

• 时间必须严格按 RFC 1123 格式，例如：Wed, 21 Oct 2030 07:28:00 GMT
• 注意：客户端系统时间错误会导致缓存提前失效或永不刷新
• Nginx 示例配置：

location ~* .(js|css|woff2|png)$ {
expires 1y;
add_header Cache-Control "public, max-age=31536000";
}

实际部署中建议同时设置两者，但以 Cache-Control 为准，Expires 仅作兜底。

前端能做的配合动作

虽然 JS 无法设置强缓存头，但可通过以下方式间接影响缓存行为：

• 构建时对静态资源文件名添加内容哈希（如 main.8a3f2d.js），确保每次变更生成新 URL，绕过旧缓存。
• 动态请求 API 数据时，避免依赖强缓存；改用 localStorage + 手动 TTL 控制，或结合 Cache API + Service Worker 实现可控缓存。
• 调试阶段可临时禁用缓存：DevTools → Network 标签页勾选 “Disable cache”，或在请求头中加 Cache-Control: no-cache（仅影响当前请求）。

验证是否生效

打开浏览器开发者工具 → Network 标签 → 刷新页面 → 查看目标资源的响应头：

• 若状态码为 200 (from memory cache) 或 200 (from disk cache)，说明强缓存命中。
• 检查 Response Headers 中是否存在 Cache-Control，且值符合预期（如 max-age=31536000）。
• 若出现 304 Not Modified，说明走的是协商缓存，而非强缓存。

《夸克》非常好用的免费AI浏览器

下载APP查看