最常见原因是浏览器缓存旧版CSS文件，需禁用缓存检查200响应、验证路径与CSP、排查加载顺序及优先级冲突，并避免preload与stylesheet混用。
检查 <link> 是否被浏览器缓存
外部 CSS 文件修改后没生效，最常见原因是浏览器缓存了旧版本。即使你刷新页面，Ctrl+F5 强刷也不一定清掉 <link> 的缓存，尤其当服务器返回了 Cache-Control: max-age=31536000 这类长效缓存头时。
- 打开开发者工具（F12），切换到
Network面板，勾选Disable cache，再刷新页面，看.css请求的响应状态码是否为200（不是304）和响应头中Last-Modified或ETag是否更新 - 临时在
<link>的href后加查询参数强制绕过缓存，例如：<link rel="stylesheet" href="style.css?v=1.0.1">
——上线前记得移除或改用构建工具自动加哈希 - 服务端配置更可靠：Nginx 中对
.css文件禁用强缓存，或设置短max-age，例如：location ~ \.css$ {<br> add_header Cache-Control "no-cache, must-revalidate";<br>}
确认 <link> 标签是否真正加载成功
样式没效果，有时根本不是缓存问题，而是 CSS 文件压根没加载进来，比如路径写错、404、跨域或 CSP 拦截。
- 在
Network面板过滤css，检查该请求是否返回200；若为404，核对href路径是否相对于当前 HTML 文件位置（不是相对于 CSS 文件自身！） - 查看
Console面板是否有类似Failed to load resource: net::ERR_ABORTED或Refused to apply style from 'xxx' because its MIME type ('text/html') is not a supported stylesheet MIME type—— 后者通常意味着服务器返回了 404 页面（HTML）而非 CSS 文件 - 如果用了 CSP（Content-Security-Policy），检查响应头中是否包含
style-src限制，且未允许该外部域名或'self'
排查 CSS 加载顺序与层叠优先级冲突
即使 CSS 成功加载，也可能因引入顺序或选择器权重被后续样式覆盖，导致“修改无效”的假象。
-
<link>必须放在<head>内，且**越靠后引入的样式表，其同权重规则越优先**。检查是否在你的style.css之后又引入了bootstrap.css或其他重置样式表 - 用开发者工具的
Elements面板选中目标元素，在右侧Styles栏观察哪些规则被划掉（strikethrough）——被划掉的说明被更高优先级规则覆盖；点击右侧文件名可跳转到对应行，确认来源 - 避免滥用
!important掩盖顺序问题；真正要改的，是调整引入顺序，或提升选择器特异性（如把.btn改成.header .btn），而不是堆!important
注意 rel="preload" 和 rel="stylesheet" 混用风险
有人为了“优化加载”把 <link rel="preload"> 和 <link rel="stylesheet"> 对同一个 CSS 文件写两遍，这反而会导致样式表被加载两次，且第二次可能因时机问题不触发渲染更新。
立即学习“前端免费学习笔记（深入）”；
- 不要这样写：
<link rel="preload" href="style.css" as="style"><br><link rel="stylesheet" href="style.css">
- 如果真要用
preload，应配合onload动态插入：<link rel="preload" href="style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
，否则浏览器可能忽略第二次rel="stylesheet"的加载逻辑 - 现代推荐用
rel="stylesheet" media="print" onload="this.media='all'"实现异步加载，更稳妥
href。 
