Ajax请求默认可能利用浏览器缓存，导致前端获取旧数据；精准控制缓存行为需通过请求头（如Cache-Control: no-cache或no-store）、URL参数（时间戳/随机数）及服务端ETag/Last-Modified协商验证协同实现。
Ajax请求默认可能利用浏览器缓存，导致明明服务端数据已更新，前端却拿到旧的响应。关键不是“禁用缓存”，而是**精准控制缓存行为**——通过请求头让浏览器知道：什么该缓，什么必须重验，什么必须跳过缓存。
设置 Cache-Control 强制不缓存（简单直接）
这是最常用也最可靠的方式。在发送请求前，手动添加请求头，告诉浏览器不要缓存本次响应：
-
XMLHttpRequest：在
open()后、send()前调用setRequestHeader('Cache-Control', 'no-cache') -
fetch：直接在
options中配置cache: 'no-store'（完全不存）或cache: 'no-cache'（每次发请求前先验证）
注意：no-cache 不代表“不发请求”，而是要求浏览器在使用缓存前必须向服务器发起条件请求（带 If-None-Match 或 If-Modified-Since），服务端返回 304 时才复用缓存；no-store 才是彻底不存储、不读取任何缓存。
添加时间戳或随机参数（防缓存兜底方案）
当无法控制请求头（如跨域且服务端未开启 CORS 允许自定义 header），可在 URL 后追加唯一参数，破坏 URL 缓存键：
立即学习“Java免费学习笔记（深入）”；
- 用
Date.now()：url + '?t=' + Date.now() - 用随机数：
url + '?r=' + Math.random().toString(36).substr(2, 9)
这种方式简单有效，但本质是“绕过缓存”而非“管理缓存”，适合临时调试或老旧系统。长期项目建议优先用标准缓存头。
配合服务端 ETag / Last-Modified 验证（高效省流量）
真正合理的缓存策略是前后端协作：服务端在响应中返回 ETag 或 Last-Modified，客户端后续请求自动带上 If-None-Match 或 If-Modified-Since。浏览器和服务端共同决定是否返回 304。
你只需确保：
- 服务端对相同资源返回稳定的
ETag（如基于内容哈希） - Ajax 请求不主动覆盖或删除这些验证头（默认 fetch / XHR 都会自动携带）
- 避免手动设置
cache: 'reload'或Cache-Control: max-age=0这类强制刷新行为，它们会跳过验证流程
检查并清理已有缓存干扰
开发中常遇到“明明改了请求头，还是拿旧数据”，可能是：
- 服务端响应里自带
Cache-Control: public, max-age=3600，覆盖了前端设置 - CDN 或代理层缓存了响应，未透传验证头
- 浏览器 DevTools 的 “Disable cache” 仅影响手动刷新，不影响脚本发起的 Ajax
排查时打开 Network 面板，点击请求 → Headers 标签页，确认 Request Headers 中有你设的 Cache-Control，且 Response Headers 中的缓存策略符合预期。
