javascript无法直接设置http响应头，禁用缓存须服务端配置cache-control等响应头；前端可通过fetch的cache选项、url参数戳、清理service worker缓存等方式配合实现。
JavaScript 本身不能直接设置 HTTP 响应头——那是服务端的职责。但你可以通过前端手段配合服务端配置，或在发起请求时显式控制缓存行为，从而达到禁用不必要缓存的目的。
服务端响应头才是根本（需后端配合）
真正禁用浏览器缓存，必须由服务端在返回资源时设置正确的 HTTP 头。前端 JS 无法绕过这一步，只能“提要求”或“配合执行”。关键响应头包括：
- Cache-Control: no-store —— 完全禁止缓存，敏感数据（如登录态、支付页）必须用；
- Cache-Control: no-cache —— 允许缓存，但每次使用前必须向服务器验证（走 304）；
- Pragma: no-cache 和 Expires: 0 —— 兼容老浏览器的辅助字段，建议一并设置。
这些头需由后端在 HTML、JS、CSS 等所有响应中统一注入，例如 Nginx 配置：add_header Cache-Control "no-store, no-cache, must-revalidate"。
fetch 请求中主动禁用缓存
对 AJAX 或 API 请求，JS 可通过 fetch 的 cache 选项控制客户端行为：
-
cache: 'no-store'—— 不缓存请求和响应； -
cache: 'no-cache'—— 强制校验，适合需实时但可协商的接口； -
cache: 'reload'—— 跳过缓存，强制发新请求（带完整响应体）。
示例：fetch('/api/user', { cache: 'no-store' })
绕过缓存加载静态资源（如 script/css）
当 JS/CSS 文件更新后用户仍加载旧版，可用 URL 参数“戳”强制刷新缓存：
- 动态创建 script 标签时拼接时间戳：
script.src = 'app.js?t=' + Date.now()； - 构建时生成哈希文件名（如
app.a1b2c3.js），让 URL 变化触发新请求； - 注意：该方法仅在服务端未设强缓存（如
max-age=31536000）时可靠；若已设长缓存，加参数无效。
清理 Service Worker 缓存（如有）
如果应用使用了 Service Worker，它可能独立维护一份缓存，不受 HTTP 头影响：
- 可通过
caches.keys().then(keys => Promise.all(keys.map(key => caches.delete(key)))))清空所有缓存； - 新版 SW 安装时，通常应在
install事件中调用caches.delete('old-cache')； - 调试阶段可在开发者工具「Application → Cache Storage」手动清除。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
