根本原因在于URL不稳定、响应头未允许缓存或link标签语义不正确：带动态时间戳的href使URL每次不同；Content-Type非text/css导致浏览器拒绝缓存；缺少rel="stylesheet"或置于body中会绕过缓存机制。
不是所有 link 引入的 CSS 都能被浏览器缓存，根本原因在于「浏览器是否把它当做一个可缓存的静态资源来处理」——而这个判断取决于三个关键环节：URL 是否稳定、响应头是否允许缓存、以及标签本身是否被正确解析。
link 标签 href 中带时间戳或随机参数（如 ?t=1730743080）
这类写法会让每次请求 URL 都不同，浏览器认为是全新资源，直接跳过缓存查找。即使服务端返回了 Cache-Control: public, max-age=31536000，也无济于事。
- 常见于手写开发环境调试代码：
href="style.css?t=<script>document.write(Date.now())</script>"，实际生成的 URL 每次都不一样 - 构建工具未配置哈希（如 Webpack 的
contenthash），却手动加了?v=1.0.0，但上线后忘了更新版本号，导致新内容仍走旧缓存 - 服务器端模板渲染时动态拼接时间戳（如
href="main.css?{{ now.timestamp() }}"），相当于主动拒绝缓存
服务器返回的 Content-Type 不是 text/css
浏览器对 CSS 的缓存前提是「它确认这是合法样式表」。如果响应头中 Content-Type 是 text/plain、application/octet-stream 或缺失，现代浏览器会拒绝解析并丢弃该响应，自然也不会存入缓存。
- 检查方式：在开发者工具 Network 面板点击 CSS 请求 → Headers → Response Headers → 查看
Content-Type - 常见于 Nginx/Apache 未配置 .css 文件类型映射，或静态文件托管平台（如 GitHub Pages、Vercel）误将 .css 当作普通文本返回
- 某些后端框架（如 Express）若用
res.sendFile()但没设headers，也可能漏掉类型声明
link 标签缺少 rel="stylesheet" 或放在 body 中
浏览器只对 rel="stylesheet" 的 link 标签启用完整加载与缓存流程。其他情况（如 rel="preload"、rel="prefetch" 或漏写 rel）不会触发样式解析，也就谈不上缓存。
立即学习“前端免费学习笔记（深入）”；
-
<link href="style.css">：完全被忽略，Network 中甚至看不到请求 -
<link rel="stylesheet" href="style.css">放在底部：部分浏览器延迟解析，可能造成 FOUC（Flash of Unstyled Content），且首次渲染后才发起请求，影响缓存复用时机 - 动态插入（如
document.body.appendChild(link)）：不触发预加载，也不进入主文档缓存链路，尤其在 SPA 中容易被绕过
真正稳定的缓存依赖 URL 不变 + 响应头合规 + 标签语义正确。三者缺一不可；其中最容易被忽略的是 Content-Type 和 rel 属性的隐式失效——它们不会报错，只是让缓存从一开始就没启动。
