返回列表后，筛选条件为什么全重置了？

先把“记住筛选条件”这句话拆开

假设有人在公开课程列表里选了设计、北部，翻到第2页，再打开海报制作的详情。看完返回时却到了全部地区的第1页。这个虚构问题不只是把筛选值保存起来，还要让已应用的条件、读到的位置与眼前的结果对应得上。否则控件看似恢复了，列表却可能已经换成另一批内容。

最初很容易想到把最后一次条件放在一个地方。但另一个标签页开始查烹饪课程后，那个全局值属于谁？如果覆盖了设计列表的条件，返回就会出错。如果还希望别人打开分享地址也能看到相同条件，只保存在当前画面里的值也不够。

所以先分成三类：已经应用的公开条件、尚未应用的编辑、这次列表访问中读到的位置。它们的保存范围、失效时机以及缺失后的处理都不同。先把下面这张表交给开发和设计，明确恢复承诺，再讨论存储方式。

哪些跟地址走，哪些只属于这次访问

MDN把pushState新增历史记录与replaceState替换当前记录区分开。URLSearchParams用来读写地址中的查询条件。这些浏览器能力不会替你决定产品规则。什么操作算一次移动、什么状态可以分享，仍然需要策划明确。

本例把类别、地区、排序、页码这些公开的已应用条件放进URL。个人搜索词和认证信息不在范围内。要返回的课程和位置则关联到具体列表访问，不使用全局最后位置。这样新标签页即使没有原标签页的位置记录，也能按地址打开相同条件。

同一地址不代表结果永远相同。课程截止或删除后，数量与顺序都会变。这里承诺的是相同条件下的当前结果。如果业务要求保留过去某一时刻的列表，就需要另外保存观察时间和结果集合，不能把当前查询包装成历史还原。

点一次应用，到底新增几条历史记录

如果在筛选面板每改一项就新增记录，用户后退时要经过许多未完成的编辑。本例在点应用前只更新草稿。应用新的类别、地区或排序时回到第1页，并新增一条历史记录。若与当前已应用状态完全相同，就不新增，避免来回经过相同画面。

翻页保留筛选和排序。后退、前进是在读取已有记录，不能又新增一条。先按该条记录的URL同步已应用条件与编辑控件，再发起查询。尚未应用的草稿不能混入上一次列表，否则地址、控件和结果会各自代表不同状态。

默认值定为全部类别、全部地区、开课日期顺序、第1页。不认识的地区、负数页码，或者同一条件键重复出现，都采用该项默认值，说明修正原因，并替换当前记录。曾经有效的页码因结果减少而消失属于另一种情况，后面单独处理。

回到列表，不代表旧响应就能直接显示

离开列表前，把来源地址、课程身份、位置和输入方式关联到该次访问。只有确认同一标签页紧邻的上一条记录就是来源列表时才后退。如果详情从外部打开或中间经过其他画面，就转到验证过的列表地址。没有来源信息时提供默认列表链接，不盲目退到外部网站。

返回后重新查询当前结果。只比较筛选条件还不够，因为同一条件也可能重试，旧请求随后才返回。因此响应必须同时属于当前访问和最新请求序号。即使已经取消旧请求，在把响应写入画面前仍然要检查，不能把取消动作当成唯一保障。

先渲染当前结果，再恢复位置。原课程仍在本页就让它可见；键盘进入详情时，把焦点还给该链接。课程不在则定位结果标题并说明列表变化。若用户等待期间已经开始另一项操作，就取消迟到的自动移动。浏览器与应用也不能各做一次恢复，需要确定唯一负责方。

原课程消失了，画面也要有明确去处

第2页可能还在，但原课程已经挪到别的页。自动遍历所有页去找它，返回会变慢，结果也可能继续改变。本例只在当前页查找。找不到就保留筛选并定位结果标题，不能因为位置恢复失败就把整个列表重置为默认条件。

查询失败时保留URL和已应用条件，并提供按相同条件重试的入口。隐藏旧结果，避免看起来像新查询的结果。正常返回零条属于成功的空状态，应与失败区分。如果请求页码超过当前最后一页，则保留条件，移到最后有效页并说明原因；零条时是第1页的空结果。这个修正替换当前记录。

下面按钮展示的是固定条件下的提示例子，不会查询真实课程服务器。分享地址在新标签页打开时，从结果标题开始显示相同条件下的当前结果，不继承别人的滚动和焦点。这样才能把可分享条件与个人这次浏览位置分开。

让AI找遗漏的跳转，别一开始就要存储代码

直接要求保存筛选条件的代码，很容易先得到某种存储实现。更适合先提供进入路径、条件确认时机、返回目标和失败处理，再让AI在这个范围内找缺口。这样你能根据已经确定的约定检查答案，而不是被实现细节带着走。

如果建议只保存最后滚动值，就追问另一个标签页、课程删除、迟到响应时，这个值属于哪次访问。如果建议全部放进URL，就让它拆分可分享的公开条件和只属于本次访问的位置。是否采用，取决于它能不能对上决策表与输入、预期结果，而不是答案有多长。

下面是未执行的提问示例。继续提问时，可以要求补充同条件重试、直接进入详情、加载期间再次修改筛选这几种情况。每增加一个条件，都要指出它进入设计说明中的哪个跳转，以及QA的哪条验收。这样才能把AI的建议变成可以核对的文档。

提问示例：我们在设计公开课程列表。用户按设计／北部／开课日期／第2页浏览，打开详情后返回。已应用条件放进URL，返回位置按列表访问保存。请检查编辑草稿与应用、后退、新标签页、课程删除、同条件重试中的遗漏，分别写出画面提示、状态变化、开发交接条件和QA预期结果。排除个人搜索词与无限滚动。

策划的决定要一直连到画面和响应

策划书记录承诺恢复什么以及哪些不在范围内。设计说明把应用、加载、失败、返回分别连接到提示和动作。只写某个存储方式的名称，可能出现看起来相同的画面，后退行为却完全不同。真正需要交接的是状态变化的依据和边界。

排序也要和开发对齐。开课日期相同时，用稳定的课程身份顺序作为次级排序，避免相同日期每次响应随机换位。但新增或删除仍然会改变分页，这不能被描述为保留过去顺序。API约定中需要能够核对已应用条件、总数与页码范围。

W3C的焦点顺序说明强调键盘操作的意义和可操作性。本例选择返回课程链接或结果标题，是考虑这个原则后的设计决定，并不是WCAG指定了这两个目标。焦点是否可见、下一次Tab是否延续当前内容，都要在实际界面验证。

不能只按一次后退就说验收完成

验收时把URL、已应用筛选的显示和实际结果一起记录。筛选恢复了，但结果来自另一个查询，同样是失败。下表是实现后应验证的条件，并不是说本文已经开发了课程服务并完成联调。设计检查与真实接口验收需要分别留下结果。

桌面和移动端要按相同顺序跳转，也要检查用键盘进入详情后的返回。把响应延迟，再在等待期间应用另一组筛选，旧结果或迟到焦点都不能抢回画面。输入方式不同，也应遵守相同的条件和失败规则，这样后续人员才能复现。

复用之前，先改成你自己列表的约定

下面的交接说明面向有页码的公开课程列表。无限滚动、个性化推荐或审计用历史列表，需要重新决定恢复范围。尤其是必须显示特定时刻的交易或工作记录时，不能直接套用重新查询当前结果的政策，否则保存的含义已经变了。

实现前，策划、开发和设计一起按同一个例子走一遍。在哪确认条件，失败后留下什么，原课程消失时去哪里，先达成明确决定，再同步到设计说明和QA。如果几份文档还留着不同默认值，就不能算交接完成。

首次上线优先阻止条件、URL和响应不一致的问题。发现这类失败时停止发布，修复跳转，再按相同顺序重新确认。部署后仍应和运营检查截止、删除导致页数减少的情况，把新发现的例外同时更新到决策表、画面提示与QA中。

公开课程列表——筛选保留与详情返回交接说明
范围：公开类别、地区、排序与页码。排除个人搜索词、登录、个性化推荐与无限滚动。
示例：设计／北部／开课日期顺序／第2页／每页20项。在同一标签页打开“海报制作”详情后返回。
保存：已应用的公开条件放入URL；尚未应用的编辑留在当前画面。课程身份、位置与输入方式按该次列表访问保存，不放入分享地址。缺失或不匹配的返回信息不能使用。
应用：应用筛选或排序时重置到第1页，并新增一次历史记录；与当前已应用状态相同则不新增。翻页保留筛选和排序。默认是全部类别、全部地区、开课日期顺序、第1页。
历史跳转：后退或前进时，用该记录的URL同步已应用条件与编辑控件，再查询，不新增记录。无效值使用已定义默认值，说明原因并替换当前记录。重复的条件键使用该项默认值。
返回操作：只有确认同一标签页紧邻的上一条就是来源列表时才后退，否则跳转到验证过的列表地址。没有来源列表信息就提供默认列表链接，不能盲目后退或接收任意外部返回地址。
响应：仅处理与当前访问和最新请求序号都匹配的响应。同条件重试也生成新序号。失败时保留条件与URL，隐藏旧结果并提供重试。零条结果属于成功返回的空状态。
位置：当前结果渲染后，若原课程仍在本页就让它可见；键盘进入时聚焦其链接。课程不在或无返回信息则定位结果标题。等待期间用户开始其他操作，就取消延迟自动移动。浏览器与应用的恢复必须只有一个负责方。
页数减少：保留筛选及排序，转到最后有效页并替换当前记录。零条时使用第1页及空结果提示。说明变化，不自动遍历所有页追找原课程。
分享：新标签页从结果标题开始显示相同条件下的当前结果，不保证旧顺序、旧数量及滚动位置。开课日期相同时，以稳定课程身份顺序作为次级排序。
责任：策划定恢复范围和例外；开发负责URL验证、历史、请求序号及单一恢复机制；设计负责条件、加载、失败、列表变化提示和焦点；QA使用12项验收条件；运营检查删除、截止及页数减少。
上线前：对齐决策表、设计说明中的状态与文案、API排序和总数约定、QA输入及预期结果。URL、已应用条件和响应不一致时阻止上线并修复。
验证范围：基于公开浏览器资料和虚构条件的设计案例，并非真实课程服务已经完成联调。

来源与示例条件

本文是虚构公开课程列表的设计案例。公开浏览器资料用于支持功能与可访问性原则，返回、默认值和失败处理是本例自行确定的政策。并非真实课程服务的联调或用户成果记录。AI提问是未执行示例，英文与中文是同一韩文案例的本地化版本。

MDN — Working with the History API

MDN — URLSearchParams

W3C — Understanding SC 2.4.3 Focus Order