根本原因是浏览器缓存了旧css文件，url未变则复用缓存不发请求；可靠解法是构建时生成contenthash文件名（如main.abc123.css）并由工具自动更新html引用，配合服务端cache-control: public, max-age=31536000。
浏览器不更新 CSS 样式，不是你改错了，而是它根本没去拉新文件——URL 没变，缓存就复用，连 HTTP 请求都省了。
为什么 style.css 改了但页面还是旧样式
浏览器把 style.css 当作一个固定地址，只要 URL 完全一致（包括查询参数），就可能直接从磁盘或内存读缓存（状态显示为 200 (from disk cache)）。你本地保存、服务器部署、甚至确认返回了新内容，都没用——因为请求压根没发出去。
常见佐证方式：
- 打开开发者工具 → Network 面板 → 刷新，看
style.css的 Status 是不是200 (from memory cache)或304 - 禁用缓存（Network 面板勾选
Disable cache）后刷新，样式立刻生效 → 基本锁定是缓存问题 - Response Headers 里有
Cache-Control: max-age=31536000或Expires远期时间 → 强缓存已生效
link 加 ?v= 参数为什么有时无效
加参数本意是让 URL 变化，触发新请求，但它失效很常见，原因不在前端写法本身，而在链路下游：
- 构建工具（如 Vite 的
build.rollupOptions、Webpack 的url-loader）默认剥离查询参数，HTML 里写的?v=abc在最终产物中被删掉了 - Nginx 或 CDN 配置了
proxy_cache_key但没包含$args，?v=1和?v=2被当成同一个缓存键 - Cloudflare 免费版默认开启
Ignore query string，直接忽略所有?后内容 - 参数写错位置，比如
style.css#main?v=1——#后内容根本不会发给服务器
真正可靠的更新方式：文件名带 contenthash
靠 URL 变化绕过缓存，最稳的方式不是加参数，而是让文件名随内容变化。现代构建工具（Webpack/Vite/Rollup）默认支持，但必须确保三件事同步：
- 输出 CSS 文件名含
[contenthash]，例如main.abc123.css - HTML 中的
<link href="/static/main.abc123.css">必须由构建工具自动注入，不能手写死 - CSS 内部的
@import "base.css"不会被自动重写，建议改用 JS 动态import()，或提前转成相对路径
这样，只要 CSS 内容一变，文件名就变，URL 就不同，浏览器自然请求新资源——CDN、Nginx、代理全都能正确区分，无需额外配置。
服务端 Cache-Control 设置不当会抵消前端努力
即使你用了 ?v=xxx 或 main.abc123.css，如果服务端对所有 .css 文件返回 Cache-Control: max-age=31536000，浏览器仍可能跳过请求（尤其在普通刷新时）。关键点：
- 开发环境可设为
no-cache或max-age=0，强制协商缓存 - 生产环境推荐
public, max-age=31536000，但前提是文件名已含哈希——否则就是“长期缓存 + 固定路径”，等于锁死旧版本 - 绝对不要对 CSS 设
immutable，除非你确认该文件永不变更；它会让某些浏览器跳过 ETag 校验，导致后续更新完全失效
最容易被忽略的是：Nginx 或 CDN 缓存配置可能覆盖源站响应头。比如全局 expires 1y 会把所有静态资源都锁死一年，哪怕你返回了 no-cache 也白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
