HTML、API 与静态资源中的 no-store、no-cache、max-age 如何区分
从真实缓存场景出发，解释认证 HTML、需要再验证的 API 与长期缓存静态资源分别适合哪种 Cache-Control 策略。
Cache-Control 的问题往往不是从明显的语法错误开始的，而是从“复制策略”开始的：一段来自 API 新鲜度文章，一段来自 CDN 配置清单，再加上一段静态资源缓存模板，最后全都堆到了同一个响应头里。头本身合法，但表达的策略已经不清楚了。
更稳妥的做法，是先从响应类型决定缓存策略。认证后的 HTML、需要再验证的 API JSON、以及带版本号的静态资源，本来就不应该共享同一套规则。只要先明确当前响应属于哪一类，后面的 header 选择就会清晰很多。
当真正的风险是“被保留并复用”时，优先考虑 no-store
如果响应绑定到某个具体用户、某个私密会话，或者内容本身较敏感，那么最重要的不是“够不够新”，而是“不要留下可复用副本”。这类场景下，no-store 才是最自然的边界。
因此，个人控制台 HTML 或高敏感 API 响应更适合 no-store，而不是再把几种较弱的 directive 混在一起。只要主要风险是“留存与复用”，而不是单纯“过期”，no-store 往往是更直接的答案。
当可以保存但必须先确认时，使用 no-cache
很多团队把 no-cache 理解成“不要缓存”，但它更接近“不要未经确认就复用”。这一点对于 API 响应和部分 HTML 很关键：它们可以被短暂保存，但下次使用前应该先确认是否仍然有效。
如果配合 ETag 或 Last-Modified 这样的 validator，这个策略就会非常清楚：缓存副本不是立刻丢弃，而是在复用之前先问一次“它还是最新的吗”。
长 max-age 和 immutable 应该只给 versioned static assets
max-age 配合 immutable 特别适合内容变化时 URL 也会变化的资源，例如带哈希的 JS、CSS、字体或图片。对于这种资源，URL 本身已经承担了版本边界，所以强缓存是合理的。
真正的问题在于团队把这套策略照搬到 HTML 或 API 上。后者通常是同一个 URL 下内容会变化的响应，更适合再验证甚至 no-store 语义。header 并不是天生错误，而是被用在了错误的响应类型上。
Cache-Control Header Checker
Review whether a Cache-Control header strategy is coherent before no-store, no-cache, max-age, immutable, and revalidation hints start fighting each other.
HTTP Status Code Explorer
Search common HTTP status codes, compare confusing client and server failures, and keep a sharper API debugging checklist in the browser.