根本原因是浏览器依据URL和Cache-Control响应头复用缓存；解决关键是让CSS URL变更（如contenthash）并配长期缓存，同时入口HTML设no-cache确保引用更新。
更新后客户端仍加载旧版 CSS，根本原因不是“缓存没清”，而是浏览器依据 URL 和响应头判断资源是否过期——只要 href 没变、Cache-Control 又设了长缓存，它就会复用本地副本。解决的关键是让浏览器「不得不」请求新内容。
检查 Network 中 CSS 请求是否真的发出了
打开开发者工具 → Network → 刷新页面，筛选 .css，观察目标文件的：状态码是否为 304（协商缓存命中）或直接来自 memory cache；Response Headers 中是否有 Cache-Control: max-age=31536000 这类强缓存指令；请求 URL 是否带查询参数（如 ?v=2.1.0）或哈希（如 app.a1b2c3.css）。如果 URL 一模一样、响应头又允许缓存一年，那浏览器不换文件才是守规矩。
HTML 中的 CSS 引入必须带版本标识
仅靠服务端设置 Cache-Control 不足以解决更新问题，因为 HTML 本身若也被缓存，就可能继续引用旧路径。最稳妥的做法是在构建阶段或部署脚本中确保每次变更都生成唯一 URL：
- 推荐用内容哈希：构建输出
main.e3f8a9b2.css，HTML 中写<link rel="stylesheet" href="/css/main.e3f8a9b2.css"> - 次选用查询参数：手动或脚本替换为
<link rel="stylesheet" href="/css/main.css?v=20261014">，注意v值必须随内容变化，不能固定写死 - 避免只改注释或空格就发版——哈希值不变，URL 就不变，缓存依然生效
Nginx 对静态资源的缓存配置要配合文件名策略
如果你已用哈希命名，Nginx 就该放心地给 CSS 设置长期缓存；但如果还用固定文件名（如 main.css），再配 expires 1y 就等于锁死旧版：
立即学习“前端免费学习笔记（深入）”；
- 正确做法（哈希文件名前提下）：
location ~* \.(js|css|png|jpg)$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br>} - 错误做法（固定文件名 + 长期缓存）：浏览器拿到
max-age=31536000后，一年内都不会再问服务器 - 入口 HTML 必须反其道而行：
location = /index.html {<br> add_header Cache-Control "no-cache";<br>}否则用户卡在旧 HTML，连新 CSS 的 URL 都看不到
验证时别信“普通刷新”，要模拟真实用户行为
开发时习惯 Ctrl+F5 或禁用缓存，但这和用户日常访问完全不同。验证是否真正解决，得关掉所有开发者工具，用无痕窗口访问，或找未访问过该站点的设备实测。最容易被忽略的是：CDN 层可能也缓存了 HTML 或 CSS，如果用了 Cloudflare 或 Nginx proxy_cache，光改源站响应头不够，还得主动 purge 或用 proxy_cache_bypass 触发回源。
