绝大多数静态 CSS 文件应设为 public，因其可被 CDN 和代理缓存，提升加载性能；private 会禁用中间层缓存，造成不必要的回源。
Cache-Control 设置为 public 还是 private？
绝大多数静态 CSS 文件应该用 public，除非它包含用户身份相关样式（比如后台主题色由登录态决定）。private 会禁止 CDN 和代理缓存，白白浪费边缘节点能力。浏览器仍会缓存 private 资源，但中间层不存——对 CSS 这种纯前端资源毫无必要。
常见错误：把所有静态资源统一配成 private，以为“更安全”，结果 CDN 始终回源，首屏加载变慢。
-
public, max-age=31536000是最常用组合（1 年），适合带哈希指纹的 CSS 文件（如main.a1b2c3.css） - 若没做文件名哈希（比如直接用
style.css），max-age别设太长，否则更新后用户可能卡在旧版本 - 开发环境建议加
no-cache或max-age=0，避免本地改了 CSS 却看不到效果
为什么不能只靠 ETag 或 Last-Modified？
HTTP 缓存协商头（ETag、Last-Modified）只能触发 304 响应，意味着浏览器仍要发一次请求去问服务器“有没有新版本”。对 CSS 这类关键渲染资源，哪怕只是 304，也多了一次网络往返延迟，阻塞页面解析。
强缓存（Cache-Control 或 Expires）能让浏览器完全跳过请求，直接读磁盘缓存——这才是优化核心。
立即学习“前端免费学习笔记（深入）”；
- 没配
Cache-Control时，浏览器可能退化为仅依赖ETag，尤其在 Nginx 默认配置下 -
ETag值如果基于 inode 或最后修改时间生成，文件内容不变但部署重传后可能变化，导致缓存失效误判 - CDN 对
ETag支持参差不齐，有些直接忽略，只认Cache-Control
Webpack/Vite 构建后 CSS 文件如何确保缓存生效？
构建工具默认不会自动设置 HTTP 头，Cache-Control 是服务器或 CDN 层的责任。但构建方式直接影响你能不能放心配长期缓存。
关键点：文件内容变 → 文件名变 → 可安全配 max-age=31536000。
- Webpack 用
[contenthash]（不是[hash]）命名 CSS 输出文件，Vite 默认已启用类似机制 - 若用了
mini-css-extract-plugin，确认其filename配置含 hash，否则 CSS 文件名固定，max-age设再长也没用 - Nginx 中对
*.css文件加add_header Cache-Control "public, max-age=31536000";，但必须确保该路径下只有带 hash 的文件，否则会缓存错
CDN 上 CSS 缓存没刷新，可能卡在哪？
CDN 缓存层级多（边缘节点 → 中心节点 → 源站），即使你改了源站响应头，边缘节点可能还拿着旧的 Cache-Control 值，尤其当源站之前返回过短缓存时间。
本质是 CDN 把“缓存策略”也缓存了——它不会实时拉取源站响应头。
- 首次回源获取 CSS 时，CDN 记下了当时的
Cache-Control值，并按此值缓存资源本身和响应头 - 后续源站改了
max-age，CDN 不会主动更新这个策略，除非缓存过期或手动刷新 - 排查方法：用
curl -I https://xxx/style.css看响应头，对比源站直连和 CDN 域名的Cache-Control是否一致 - 解决办法：发布新 CSS 后，强制刷新 CDN 缓存（或删掉旧文件路径），别指望它自动同步头信息
