大屏阅读工作台的目录与详情已经能够保持一致：Navigation 负责详情历史，重复点击不会制造多余页面；切换窗口后，阅读位置依靠段落锚点恢复；正文异步回写受当前文章标识与页面激活状态约束；轻量书签则由 ArkData Preferences 保存。读者的下一种操作更加普通——读完“城市光谱”以后，连续打开相邻文章。此时页面可能频繁经历内容读取、格式整理和重新排版，明明文章已经打开过，却还需要再次

双栏阅读工作台已经能够在目录中打开文章，并且能够识别重复点击，避免相同的详情页面连续压入导航栈。不过，读者在“峡谷行记”“城市光谱”“云端书签”之间来回浏览时，另一类状态偏差会出现：右侧详情已经退回前一篇，左侧高亮仍停留在离开的文章上。视觉上的选中项与实际阅读位置分离，接下来的点击、搜索和阅读记录保存都会受到影响。 从实现上看，目录高亮由 selectedId 控制，详情历史则交给 NavPath

在阅读工作台里，窗口变窄并不意味着读者改变了阅读对象。平板从横向双栏切为纵向单栏、折叠屏进入较小窗口，布局会重新计算，但读者刚刚看到的段落仍应留在视线附近。如果仅保存 Scroller 的像素偏移，文字换行之后，同一偏移可能落到完全不同的句子。对于有图片、标题和长段落的文章，这种偏差会随着内容高度变化逐渐放大。 阅读工作台已经完成目录与详情路由衔接、重复选择去重、返回后目录高亮同步。三条文章记录继

阅读工作台已经具备目录与详情分栏、重复点击去重、返回后的选中态同步、段落锚点、异步回写保护和书签存储。随着文章列表支持修订与下架，这些机制又会遇到一个共同问题：目录已经更新，路由栈里仍保留旧文章，书签指向被移除的内容，预取缓存可能装着上一版正文。三个对象各自看着正常，组合起来却会出现左栏无法选中、右栏仍显示旧稿的情况。 最容易被忽略的时机是进入阅读工作台时恢复上次会话。假设用户上次打开“城市光谱”

在大屏阅读应用里，双栏布局最容易被忽略的并不是左右宽度，而是右侧还没有任何详情页面时应该显示什么。目录已经加载完毕，读者尚未选择文章，右侧留着一大片空白，会让整个页面看起来像内容缺失。若为了消除空白而在启动时强行打开第一篇文章，又会把“默认展示”误写为“读者已经选择”。这两种处理都可能影响后续的阅读位置恢复、返回路径和目录高亮。 阅读工作台采用一份目录数据驱动导航列表，右侧详情则交给 Naviga

目录中连续点击同一篇文章，是大屏阅读应用经常遇到的一次交互。单次点击能够打开详情，并不意味着双击、触控抖动或列表刷新之后的重复触发也能得到稳定结果。假如每次都直接向 NavPathStack 压入页面，用户看见的还是“峡谷行记”，栈中却可能已经堆积了多个参数相同的 ReaderDetail。返回时需要退出多次，右侧高亮看似正确，实际路由历史却越来越长。 阅读工作台此前已经把目录记录与详情页关联到稳

大屏阅读工作台已经把目录和详情拆开处理：目录以稳定文章标识决定高亮，Navigation 管理可返回的详情历史，窗口尺寸变化时则利用段落锚点找回阅读位置。至此，读者即使在宽窄窗口间切换，也有机会回到原先阅读的段落。但详情数据如果需要异步加载，还会出现一种更隐蔽的错位：前一篇文章的读取结果晚到，覆盖了用户后来打开的文章。 例如从“峡谷行记”切换到“城市光谱”，前者内容较大，读取过程较长；后者很快返回

一套面向折叠屏和平板的阅读工作台，不能把用户的阅读位置完全寄托在当前页面组件上。此前的工程已经建立了 Navigation 的目录与详情关系，完成了重复入栈去重、返回后的目录高亮、窗口尺寸变化时的段落锚点恢复，并为异步正文设置了文章标识和激活代次。下一步要解决的是关闭应用再打开以后，阅读位置还能不能准确回来。 这个问题看起来只是保存一个字符串，实际涉及三份经常被混淆的数据：路由历史说明读者怎样走到

说明：本文代码为基于官方接口签名整理的工程示例，日志、页面、状态均是用于讲解的预期演示数据，不代表已经完成真机调试。它们是 FocusRelay 自己的显示状态，不是平台新提供的枚举。

说明：本文代码为基于官方接口签名整理的工程示例，日志、页面、状态均是用于讲解的预期演示数据，不代表已经完成真机调试。它们是 FocusRelay 自己的显示状态，不是平台新提供的枚举。