G4.07.4explain why position restore failed设计研究
位置恢复失效需说明原因，例如内容已被删除或重排
别名: 恢复失败说明 · deleted item · 内容重排 · restore failure reason
概念解释
按对象去恢复位置，对象却不在了：被删、被合并、被筛出当前集合、被别人挪到另一页。这时系统无法再把视口对准「那一条」。失效要说明原因——落到一个诚实的替代位置（邻项、列表顶、该集合的空状态），并用一句话说清为什么不是原来那一带。沉默地停在空白或默默回顶，人会当成恢复功能坏了。
机制
恢复承诺的是连续性：「你离开的世界还在」。对象消失后连续性做不到，但解释可以保住模型：世界变了，不是导航丢了书签。没有原因的回顶和「根本没做恢复」在表面上无法区分，下一次人会放弃依赖返回。删除、权限收回、重排、过滤条件过期，在实现里是不同分支，对用户却都是「那一条不在了」；原因必须落到可理解的那一层（「这条已删除」「列表已按新排序重排」），而不是 HTTP 状态码。
替代落点也在说话。停在原像素的空白，像是缺了一块；停在一条毫不相关的新热帖上，像是被推荐系统劫持。邻项或「已不在当前筛选，已回到全部」是还能接上任务的落点。说明是一次性的，刷掉就消失，不要变成永久横幅。
怎么研究
让人从一条即将失效的项进详情（实验者在离开期间删除、重排或改筛选），返回，比较无说明回顶、有说明落到邻项、有说明但落在无关项。
- 因变量：是否把结果解释为「系统丢了位置」、是否能继续当前任务、原因复述是否正确。
- 自变量：失效类型（删除 / 重排 / 筛出）、是否给原因、替代落点。
- 方法论注意点：内部员工知道实验会删数据，会预先把失败归因于删除。要用他们以为集合没变的指导语。原因文案不要出现实现词（「锚点 miss」）。几种失效不要共用一句「内容已更新」，否则测不出人能不能分辨。
边界
恢复其实成功了，只是周围插入了新项，那是按对象对齐，不该报失效。用户自己在详情里删的，回来看到邻项加一句即可，不必像系统故障那样致歉。高频刷新的行情列表几乎每秒都在重排，逐次说明会造成噪声，改为「实时重排，位置仅作大约」的一次声明。
怎么落地
- 恢复找不到 id 时，按原因分支：删除 → 邻项或列表并写「原条目已删除」；重排 → 仍尽量找 id，找不到则顶并写「列表已重排」；筛出 → 提供「清除筛选以找到它」而不是假装还在当前结果里。
- 不要在失败时沿用离开时的像素偏移。
- 说明出现在列表顶部或原锚点附近，一次，可关掉。
- 验证：对同一条分别做删除、改排序、改筛选三种离开期间变化，返回。三种都应能让未参与设计的人用自己的话说出为什么不在原处，且列表不是一片空白。无文案的回顶三次都算失败。