为什么设置了Cache-Control还是频繁请求资源？

志青 Dev 提问于 2026-02-16 01:01:32 阅读 28

优化

我在开发单页应用时给API接口设置了Cache-Control:max-age=30，但发现每次页面刷新都会重新请求JSON数据，明明应该缓存30秒才对。

代码是这样写的：

fetch('/api/data', {
  headers: { 'Cache-Control': 'max-age=30' }
}).then(res => res.json())
  .then(data => console.log('fetched:', data));

检查浏览器网络面板发现响应头确实有cache-control: max-age=30，但状态始终是200而不是304或从缓存加载。难道是因为用了fetch API特殊处理？或者需要额外设置其他HTTP头？

我来解答赞 4 收藏

反馈

1 条解答

UX浩圆 Lv1

你遇到这个问题主要是因为对HTTP缓存机制的理解有些偏差。咱们先说解决方案，然后我再解释一下为什么会出现这个情况。

首先，Cache-Control 是服务器响应头里设置的，而不是在客户端请求头里设置的。你现在的代码是把 Cache-Control 写在了 fetch 的请求头里，这其实是无效的。浏览器不会根据请求头里的 Cache-Control 来决定是否使用缓存，而是根据响应头里的 Cache-Control。

正确的做法是，在服务器端返回的响应头里加上 Cache-Control: max-age=30。比如如果你用的是Node.js和Express，可以这样写：

app.get('/api/data', (req, res) => {

  res.setHeader('Cache-Control', 'max-age=30');

  res.json({ data: 'your data here' });

});

另外需要注意的是，如果服务器同时返回了 ETag 或者 Last-Modified，浏览器可能会优先尝试协商缓存，也就是发送条件请求（比如带 If-None-Match 或 If-Modified-Since 头）。这种情况下，状态码可能是304，但本质上还是走缓存的。

还有一点要特别提醒：如果你的API接口涉及敏感数据，比如用户信息或者认证相关的内容，一定要小心缓存带来的安全问题。建议你在响应头里加上 Vary: Authorization 或者 Vary: Cookie，确保不同用户的请求不会因为缓存而被混淆。像这样：

res.setHeader('Cache-Control', 'max-age=30');

res.setHeader('Vary', 'Authorization');

最后补充一句，调试缓存问题的时候，别忘了清除浏览器缓存或者用隐身模式测试，不然可能被之前的缓存行为干扰，导致你以为代码没生效。我自己就经常被这个坑到，真是又累又烦。

总结一下，把 Cache-Control 放到服务器响应头里，注意安全相关的头设置，问题应该就能解决。

2026-02-16 02:01