问题：编辑文档时显示的文档不是刚刚浏览的。

# cat /etc/os-release 
NAME="Rocky Linux"
VERSION="9.5 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.5"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.5 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.5"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.5"

  搜索结果这条路径和左侧目录切换不一样：

  - 左侧目录点击：走 static/js/kancloud.js:186 的 loadDocument()，成功后会触发 article.open。
  - article.open 会在 static/js/kancloud.js:4 写入：

  sessionStorage.setItem("MinDoc::LastLoadDocument:" + window.book.identify, $param.$id)

  但搜索页结果在 views/search/index.tpl:31 是普通链接：

  <a href="/docs/{book}/{doc}" target="_blank">

  它直接打开详情页，没有经过 loadDocument()，也就不会触发 article.open，因此不会写：

  MinDoc::LastLoadDocument:doc-id-11

  然后你点详情页里的“编辑”，地址是：

  /api/doc-id-11/edit/

  编辑页没有从 URL 拿到具体文档 ID，于是走 static/js/editor.js:34 的兜底逻辑：

  if (window.selectedDocId) {
      ...
  }

  var $selectedNodeId = sessionStorage.getItem("MinDoc::LastLoadDocument:" + window.book.identify)

  if (!$isSelected && $selectedNodeId) {
      ...
  }

  if (!$isSelected && window.documentCategory.length > 0) {
      // 选第一篇
  }

  所以当搜索进入详情页时，如果没有 MinDoc::LastLoadDocument:doc-id-11，编辑器就无法知道“刚刚阅读的是哪篇”，只能选
  sessionStorage 里的旧值或第一篇。你说的“随意定位一篇”就是这个兜底行为。

  更严谨的复现步骤应该是：

  1. 清掉当前项目的记录：

  sessionStorage.removeItem("MinDoc::LastLoadDocument:doc-id-11")

  2. 从全局搜索结果页点击某条文档记录，进入：

  /docs/doc-id-11/doc-id-11-1h6f623fcq

  3. 不点击左侧目录，直接点“编辑”。
  4. 进入：

  /api/doc-id-11/edit/

  5. 编辑页因为没有 URL 文档 ID，也没有 MinDoc::LastLoadDocument:doc-id-11，会按兜底逻辑选第一篇或旧状态，不一定是搜
     索打开的那篇。

  结论：问题根因是 搜索结果打开详情页没有同步写入当前文档选择状态，而编辑入口又没有携带文档 ID，导致编辑页只能依赖不
  可靠的 sessionStorage/默认文档。