CDN 缓存设计：先定义边界，再讨论命中率

缓存并不只是“把 TTL 调大”。一套可靠的缓存策略，需要同时回答三个问题：什么内容可以共享、哪些请求应该被视为同一个对象，以及内容变化后如何失效。

Cache Key 决定共享边界

如果响应会因为语言、设备类型或登录状态发生变化，这些维度就必须进入 Cache Key，或者该响应根本不应该进入共享缓存。

相反，把所有请求头和查询参数都放进 Cache Key，虽然安全，却会制造大量低复用的缓存对象。

TTL 不是唯一的一致性机制

短 TTL 可以降低陈旧风险，但也会增加回源。对于发布频率不高、内容路径稳定的博客，更好的做法通常是：

1. 静态资源采用版本化文件名和较长 TTL。
2. HTML 使用可重新验证或较短的浏览器缓存。
3. 发布时主动刷新需要立即变化的 URL。

观察真实结果

上线后应关注实际的缓存状态、回源比例和内容更新路径。命中率只是结果指标，真正值得优化的是用户延迟、源站负载和内容正确性之间的平衡。