1. Cache-Control 与 immutable/max-age 在 hash 文件与版本目录策略的工程取舍
问题
请说明 Cache-Control 中 max-age 与 immutable 在 hash 文件名和版本目录两种发布策略下的工程取舍？
考察点
- Cache-Control 指令语义（max-age、s-maxage、immutable、no-cache、no-store）
- 内容寻址（hash 文件名）与版本目录（/v1/）两种策略的缓存失效差异
- 缓存层级与发布时的原子性
答案
对带内容 hash 的文件（如 app-8f3a2b.js），资源内容与 URL 一一对应，内容变化则 hash 变化而 URL 改变，因此可以放心使用 Cache-Control: public, max-age=31536000, immutable 实现一年长缓存，永不重新验证，因为 URL 变化本身就是失效手段。而版本目录（/v1/app.js）中 URL 不变，发布时需显式改目录名或更新引用，若仍用长 max-age 且缓存未随发布清空，旧版本会滞留。immutable 表示内容在生命周期内绝不变，浏览器可跳过 revalidation，只在 hash 文件上安全；非 hash 文件使用 immutable 会导致旧内容长期滞留。工程取舍上，hash 文件追求"长缓存 + 不改即不重新请求"，版本目录则需配合服务端缓存失效或版本号参数。
解析
核心是"缓存内容是否随 URL 唯一确定"。hash 文件天然满足"URL 变才改内容"，所以可以极致长缓存；版本目录内容与 URL 非一一对应，必须依赖发布时主动失效或短缓存，二者不可混用，否则出现缓存脏数据。
示例代码
# hash 文件：nginx 配置
location /static/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
# 版本目录：更保守，允许重新验证
location /v1/ {
add_header Cache-Control "public, max-age=60, must-revalidate";
}