G4.03.3persisted navigation state has a TTL设计研究
状态保持有时效，过期需说明
别名: 状态过期说明 · session TTL · 筛选过期 · stale persisted state
概念解释
列表的滚动位置、筛选、排序被留下来，是为了服务这一次还没做完的浏览，不是为了永久改变这个人与这个集合的关系。状态保持有时效：会话结束、隔了太久、登录态换了，这份快照就该失效。失效时必须让人知道「你上次的收窄已经过期，现在看到的是默认集合」，而不是默默交出一份既不像默认、也不像记忆的残片。
机制
短期记忆里的「我筛过未读」会在离开任务后衰减。隔夜再打开同一列表，人已经按默认集合在做计划；若系统仍应用昨天的 facet，结果集对不上计划，人会以为数据坏了或权限变了。sessionStorage 随标签页死，localStorage 和账号侧偏好会活过这次意图。把一次浏览的临时裁剪写成长期偏好，等于让过期意图幽灵般出现在新任务里。
过期而不说明，失败是无声的：控件可能已熄灭但请求还带着旧参数，或控件仍亮着数据却是新默认。两种不一致都比「我们已重置」更难诊断。TTL 的选择是任务半衰期：逛商品可能是这次标签页；筛工单可能是这一班；「仅看我的草稿」可能该跟账号走。没有声明的保持，等于把实现细节（哪种存储）暴露成产品行为。
怎么研究
让人设好非默认筛选，按三种间隔再打开同一列表：立即返回、关闭标签数小时后、换设备或清会话后。比较有 TTL 并提示、有 TTL 不提示、无 TTL 永久记住。
- 因变量：是否把当前集合当成「还是我设的」、发现不一致的时间、错误地以为数据丢了或筛坏了。
- 自变量：存储层（session / local / 账号）、过期是否有一句说明、间隔时长。
- 方法论注意点：实验室里的「过了很久」常用加速时钟，人的记忆衰减不跟着加速。更硬的做法是隔天远程会话，而不是在同一小时内假装隔夜。不要把「账号级默认排序」和「本次筛选」混成一个 TTL——两者的合理寿命不同，混测会得出「所有状态都该永久」或「所有状态都该即抛」。
边界
用户刚亲手点过的筛选，即使跨过了名义 TTL，也不该在下一次绘制时偷走；TTL 针对的是离开之后的静默恢复，不是正在进行的操作。明确保存的「我的视图」是用户意图的长期对象，不适用浏览往返的过期规则。法律或安全要求每次进入都从无筛选开始（共享柜台、病人列表），这时不该保持，说明也不是「过期了」而是「此处不记住筛选」。
怎么落地
- 为滚动、筛选、排序分别规定寿命：滚动跟本次会话；筛选默认跟标签页或登录会话；只有用户点过「保存为默认」的才进账号。
- 过期后回到产品默认，并在列表上给一次性说明（「筛选已过期，当前为全部」），不要留下一半亮起的芯片。
- 不要把 session 里的临时 facet 在无提示的情况下写入 localStorage。
- 验证：设好筛选，关标签等过 TTL，再打开。集合应是默认，并看得到过期说明。同一会话内立即往返仍应保留。把实现改成永久 localStorage 作为反例，隔天打开应能抓到「幽灵筛选」——那就是这条要消灭的行为。