G4.03.2keep filters and sort across round-trips设计研究
筛选与排序状态需在往返间保留
别名: 筛选往返保留 · filter persistence · 排序保持 · facet state
概念解释
用户把列表收成「仅看未读、按价格从低到高」再点进一条，返回时这组约束应还在。筛选与排序在往返间保留，指的是查询条件作为这次浏览任务的一部分活过详情页，而不是每次回到列表都回到全量默认。它不管滚动停在哪，也不管这组条件能活几天；它管的是这一来一回不要把已经付过的收窄作废。
机制
筛选和排序是人对集合做过的一次裁剪。裁剪的代价是点选、等待、确认结果还对。进入详情被理解成「在这个已经裁过的集合里看一条」，不是「离开这个集合」。返回若丢掉 facet 和 sort，集合变回未裁剪的世界，刚才那一条可能跑到几十屏之外，人以为对象丢了。更糟的是筛选控件看起来还亮着，数据却是全量——控件与内容打架，人会不信任所有过滤。
工程上失败来自把条件只放在组件内存里：详情是另一条路由，列表被销毁，回来走默认 query。URL 或会话里没有 facet，刷新和分享也会丢，但往返丢失发生得更早、更频繁。把条件写进 URL 能扛住返回和刷新；只写进内存扛不住卸载。人无法从详情页看出列表侧还记不记得这些条件，所以失败总是在返回那一帧才被发现。
怎么研究
让人先加上至少两个筛选项并改排序，打开一条，返回，看集合是否仍是那一裁。
- 自变量：条件存在哪（仅组件 state / sessionStorage / URL query）、详情是否与列表同路由。
- 因变量：返回后筛选项与排序是否仍生效、控件状态与结果是否一致、人是否重新点一遍相同的筛选。
- 方法论注意点：只设一个筛选项容易被默认值碰巧撞上。要用「非默认排序 + 至少一个非默认 facet」。对照里加上「从列表新开一条深链进入详情再返回」——若条件在 URL 里，这条路径也应保住；只在内存里的，这条会丢，能把实现拆开。
边界
用户在详情里做了会推翻当前筛选的动作（把「未读」标成已读、删除了唯一匹配项），返回后原筛选可能变成空集，应保留条件并展示空，而不是偷偷清掉筛选假装还有数据。全站级的「默认排序」被账号设置改掉时，会话内的临时排序与账号默认冲突，要决定谁赢，不能两者都亮。管理后台若把筛选写进可分享 URL，往返保留会变成「把别人的筛选带到我的会话」，需要的是打开时确认，不是静默继承。
怎么落地
- 把当前 facet 和 sort 写入列表路由的 query（或同等的可恢复会话），进入详情用 push，返回自然带回同一 query。
- 列表控件的亮起状态必须从同一份条件渲染，禁止控件记得、请求忘了，或反过来。
- 不要在进入详情时 replace 掉列表那一帧的 query，否则返回落到无筛选的列表 URL。
- 验证：选两个非默认筛选、改一次排序，进详情，返回。结果集合、控件亮起、地址栏条件三份一致。再从该详情复制 URL 在新标签打开后返回列表，条件仍在才算写入了可恢复层，而不只是内存。