Cache-Control 头构建器
按 RFC 9111 组装有效的 Cache-Control 头。勾选所需指令（no-cache、no-store、immutable 等），设置新鲜度窗口（max-age、s-maxage、stale-while-revalidate、stale-if-error），并复制生成的头。包含覆盖最常见部署模式的四个预设：不可变静态资源、私有渲染页面、带 stale 服务的公共 API 响应，以及完全 no-store。
—
预设
可见性
新鲜度（秒）
指令
输出
Cache-Control: public, max-age=3600no-store 会覆盖所有其它指令 — 开启时仅额外输出 no-transform。
使用方法
- 从与你场景匹配的预设开始，再做调整。
- 数字字段单位为秒 — 留空则完全省略该指令。
- 把结果复制到源服务器、CDN 规则或框架的响应头中。
常见问题
- 什么时候应该用 immutable？
- 用于文件名包含内容哈希的资源，并配上较长的 max-age（常用一年）。这样浏览器在软刷新时会跳过否则会做的条件再验证。
- no-cache 与 no-store 区别？
- no-cache 指存储的副本必须在使用前再验证；no-store 指根本不存储。响应含绝不能落盘的私有数据时应优先使用 no-store。
- 我设置了头部，却什么都没被缓存，怎么办?
- 多数情况是这三条之一。带着 Set-Cookie 一起返回的响应，会被共享缓存当作私有内容，CDN 通常直接跳过。带凭据发出的请求，除非你明确允许，否则共享缓存不会存储。还有，浏览器的刷新无论头部怎么写都会去重新验证，所以用强制刷新测试时，看起来永远像是头部被忽略了——请改为在新标签页里打开这个 URL。
- 它和 Expires、ETag 是什么关系?
- 两者同时存在时，max-age 胜过 Expires；Expires 只对老到看不懂 Cache-Control 的缓存才有意义。ETag 和 Last-Modified 则完全是另一套机制：它们不影响新鲜度，而是在响应过期之后让请求变便宜，使服务器可以回一个不带正文的 304。这两者本来就是配合使用的。
相关工具
HTTP 头部参考
约 50 个标准 HTTP 请求、响应、CORS、缓存、安全、Cookie 头部的可搜索参考。
开发 0 0
HTTP Basic 认证编码器/解码器
把 `用户名:密码` 编码成 Base64 `Authorization: Basic` 头 —— 或粘贴一个现有头查看里面是谁。
网络 0 0
HTTP 状态码参考
可搜索的全部 HTTP 状态码（1xx-5xx）参考 — 含概要、RFC、使用时机与常见陷阱。
网络 0 0
HTTP Cookie 解析器
粘贴 `Cookie:` 请求头或 `Set-Cookie:` 响应头，查看每个 cookie 的名称、值、属性和警告。
开发 0 0
日期格式转换
输入任意格式日期（ISO、RFC、Unix epoch、locale），同时显示 14+ 种标准格式。
时间 0 0
CORS 头构建器
从清单组合 Access-Control-* 响应头，提供四个预设并对危险组合实时警告。
网络 0 0