Pending 缺陷：智能模式未对齐 Discourse 原生楼层已读 / 后台读进度行为

[BobDLA]

背景

当前扩展的智能预览是基于 topic JSON 的抽屉阅读视图，不是 Discourse 原生 topic page。

这里的已知差异仅限 智能模式。

• 整页模式 / 原帖完整页面不在这个问题范围内
• 当前需要关注的是：智能模式下的楼层已读/未读体验，以及后台读进度推进，暂时不能保证与 Discourse 原生一致

这个问题不只是 UI 细节。

原生读进度除了影响楼层未读状态外，还会影响后台阅读相关统计。这类统计本身有实际价值，在依赖阅读行为做活跃度或等级判断的站点里，影响会更明显。

缺陷描述

当前智能模式存在以下缺口：

• 楼层级已读/未读状态未对齐原生
• 抽屉内阅读行为不会完整推进原生后台读进度
• 因此，智能模式中的阅读结果，可能和原站整页阅读后的状态不一致

换句话说：

• 用户在智能模式里看到哪一层
• 不一定能像原生一样推进对应状态
• 也不一定能像原生一样影响后台阅读计数

影响

1. 体验影响

• 智能模式中的楼层已读/未读状态，可能和原站不同
• 用户在抽屉里读过内容后，回到原站时，状态可能不符合预期
• 因此智能模式当前不能承诺“和原本一样的阅读体验”

2. 统计影响

• 原生读进度不只是视觉状态，还关系到后台阅读统计
• 这些统计在部分场景下会影响用户阅读数据、活跃度，甚至等级相关指标
• 因此这不是一个纯样式问题，而是一个带实际后果的行为差异

可选方向对比

维度	路径 A：复用原生接口，但采用简化同步规则	路径 B：尽量复刻原生读进度语义
核心思路	请求走 Discourse 原生接口，但扩展自己决定“看到哪一层算已读、何时上报、如何合并”	不仅走原生接口，也尽量模仿原生的可见性跟踪、阅读时长累计、批量 flush、节流/退避等机制
已读判定	由扩展自定义简化规则决定，例如按楼层进入视口、停留时间、批量上报策略推进状态	尽量按原生机制决定，例如可见性跟踪、阅读时长累计、原生风格 flush 与状态推进
与原生差异的主要来源	判定规则是扩展自定义的，虽然接口相同，但语义可能和原生不同	主要风险不在规则本身，而在实现是否足够接近原生、是否有边界遗漏
实现难度	中	高
改动规模	中	高
维护复杂度	中。第一版更轻，但后续如果继续往原生靠，可能需要返工	高。需要长期维护更多状态和时序逻辑
服务端负担风险	低到中。因为更容易主动控制请求频率	中。需要更精细地处理 flush、节流、退避，否则更容易出问题
违规/异常风险	低到中。风险主要来自“接口像原生，但上报语义不像原生”	低到中。理论上更接近原生会更稳，但实现复杂，边界处理不好也会异常
与原生不一致风险	中到高。主要由简化判定规则引起	低到中。主要由复刻不完整或边界遗漏引起
用户体验差异	中。可能出现“整体能用，但局部细节和原站不一样”	低。做对时最接近原站，但做错时排查更难
优势	更容易落地、频率更容易控制、适合作为第一阶段	最接近“和原本一样的体验”，长期一致性更好
劣势	最容易出现语义偏差，尤其是在局部未读、跳楼、边界推进上	开发成本、维护成本和实现风险都更高
更适合的定位	第一阶段候选方案	更理想的最终目标

为什么暂时先 pending

这个问题暂时不直接进入实现，主要原因是：

• 当前 smart mode 不是原生 topic page，无法直接无损复用原生整套逻辑
• 如果要同步到 Discourse，需要谨慎处理请求时机、频率和同步语义
• 如果实现方式偏离原生，可能带来：
  • 与原生体验不一致
  • 对官方服务器造成额外压力
  • 状态异常或边界行为偏差
  • 潜在的违规风险或误判风险

所以当前结论不是“这个需求不重要”，而是：

• 这个缺陷真实存在
• 价值也明确
• 但在同步路径和风险边界没有收敛之前，暂时先挂起

当前状态

• pending
• 作为已知缺陷保留
• 也作为提醒：当前智能模式还不能承诺与 Discourse 原生楼层已读 / 后台计数完全一致