内联CSS无法被缓存，因其无独立URL，随HTML传输且无HTTP缓存机制；外部CSS需配合哈希文件名与Cache-Control: public, max-age=31536000, immutable才能启用强缓存。
内联 CSS 为什么无法被缓存？
写在 中的内联 CSS（即 ）**根本不会进入 HTTP 缓存流程**——它随 HTML 一起传输，没有独立的 URL，浏览器无法为它单独建立缓存条目。哪怕你刷新页面，这段 CSS 都得跟着 HTML 重新下载一遍。
常见错误现象：network 面板里看不到该 CSS 的缓存状态（如 200 (from memory cache) 或 304），只看到 HTML 请求体积变大；首屏快了，但后续访问毫无缓存收益。
- HTML 文件本身通常设为
Cache-Control: no-cache或短max-age，所以内联 CSS 实际上每次都在“裸奔”加载 - 构建工具（如 Webpack/Vite）无法对内联 CSS 做哈希指纹（
main.8b2d3f.css），也就没法利用「文件名变更 → 强缓存失效」这个关键机制 - 服务端无法单独设置它的
ETag或Last-Modified，协商缓存完全失效
外部 CSS 文件如何真正启用强缓存？
只有通过 引入的外部 CSS，才能被浏览器按标准 HTTP 缓存规则处理。关键不在“外链”本身，而在于服务端是否正确设置了响应头。
实操建议：给所有静态 CSS 资源配置长缓存 + 内容哈希命名：
立即学习“前端免费学习笔记（深入）”；
Cache-Control: public, max-age=31536000, immutable
-
max-age=31536000（1 年）确保强缓存长期生效，避免重复请求 -
immutable告诉浏览器：该资源在整个生命周期内不会改变，即使用户手动刷新也不必发条件请求（跳过协商缓存） - 必须配合构建时生成带内容哈希的文件名，例如
style.29acdf.css；否则更新后用户仍会用旧缓存 - 注意：Nginx/Apache/CDN 都需显式配置这些 header，光靠前端打包不生效
为什么 CSS 放磁盘缓存（disk cache）而不是内存缓存（memory cache）？
浏览器默认把 CSS 存进 disk cache，不是因为“不够快”，而是出于资源特性和内存管理策略：CSS 是渲染阻塞资源，需要持久化、跨页面复用，且体积通常不大但需稳定存在。
常见误解：以为“内存更快就该放内存”。但实际中：
- JS 更倾向进
memory cache（尤其小体积、执行频繁的模块），因为执行后可能立刻被 GC，没必要落盘 - CSS 解析结果（选择器树、样式规则）会被浏览器内部缓存（如 Chrome 的 Rule Cache），但这和 HTTP 缓存是两层事——前者是运行时优化，后者是网络层节省
- 若你发现 CSS 总是
from disk cache却加载慢，问题往往出在磁盘 I/O 或缓存未命中，而非该放哪；应优先检查是否用了哈希文件名 + 正确Cache-Control
关键 CSS 内联 + 其余外链：怎么避免缓存冲突？
“首屏关键 CSS 内联”是性能优化常用手段，但它和外部 CSS 的缓存策略天然矛盾：内联部分无法缓存，外链部分又不能提前加载。必须用明确的加载隔离来规避冲突。
正确做法不是“一边内联一边外链就算完”，而是让两者职责清晰、互不干扰：
- 内联部分仅包含渲染首屏必需的最小样式（
是经典 trick，避免阻塞） - 所有非关键样式必须外链，并确保其
href是带哈希的独立 URL，和 HTML 完全解耦 - 禁止在内联 CSS 中用
@import引入外部 CSS——这会让内联部分变成“伪内联”，既失去内联优势，又破坏外链缓存链路 - 如果用构建工具自动提取关键 CSS（如
critters插件），确认它没把哈希后的外链 CSS 地址硬编码进 HTML —— 否则缓存更新会失效
最容易被忽略的一点：内联 CSS 里的 url()（比如背景图、字体）仍然走独立 HTTP 请求，它们的缓存行为完全独立于内联块本身，务必单独配置好这些资源的 Cache-Control。
