2026年了，把筛好的列表链接发到群里，同事打开却是全部数据，问题出在哪？

React 里把筛好的列表链接发出去，同事打开却是全部数据，多数不是链接坏了，而是筛选条件只活在组件内存里，没写进 URL。2026 年按项目交付习惯，判断顺序是：能靠一条链接复现、能发给别人的状态放 URL；跨会话该记住、又不涉及权限的放本地存储；只在当前这次浏览里有效的留在内存。三者不是替代关系，混着用才是常见返工源头。

先分清状态的三种寿命

在 React 项目里，“状态”这个词被用得太宽。按寿命划分，大致只有三类：一次渲染内有效的（表单输入中间值、弹窗开关）、一次会话内有效的（列表筛选、分页、滚动位置）、跨会话有效的（语言、主题、草稿、已读标识）。判断标准可以压缩成一句话：状态的寿命决定它的存放位置，而不是由写代码时顺手用哪个 API 决定。把跨会话状态留在组件内存里，等于默认用户不会刷新；把仅本次会话才有效的状态写进 URL，链接会变得又长又难分享。

• 渲染内状态：组件 state 或 ref，组件卸载即丢弃，不需要额外处理。
• 会话内状态：路由参数、URL 查询串，或在单页应用内做会话级缓存。
• 跨会话状态：localStorage、IndexedDB，必要时同步到服务端，由账号决定归属。

为什么位置放错，联调之后才暴露

这类问题的特点是开发自测全绿，因为开发者习惯一路点下去、很少回退。真正的暴露点集中在三个动作：刷新、把链接复制给同事、从收藏夹再打开一次。2026 年多端场景更常见，同一个页面可能同时存在于 H5、小程序和 App 内嵌 WebView 中，而各端的刷新语义并不完全一致。常见后果有：刷新即丢，用户以为页面坏了；链接不可复现，同事打开看到默认筛选；浏览器后退回到列表页，筛选被重置；同一域名下多个标签页写同一份本地存储，后写的覆盖先写的。

三问定位置：一个可以照着问的判断框架

我在交付里常用的是一个三步提问法，顺序不宜调换，因为第一问的答案会否掉后面两问。它不保证方案优雅，但能挡住大部分“放错地方”的情况。

1. 这个状态是否决定页面上看到什么内容？如果是，优先放 URL，它天然可分享、可后退、可收藏。
2. 没放 URL 的话，用户关掉标签页再回来，是否希望它还在？如果是，放 localStorage 或 IndexedDB，并提前想清楚清理时机。
3. 它是否需要跨设备、跨端，或跟着账号走？如果是，本地存储不够，要落到服务端，前端只做读取与缓存。

每一步的注意点不同：第一问要注意 URL 参数的可读性，别把整个对象序列化后硬塞进查询串；第二问要给存储结构留版本号，字段改版时能识别旧数据；第三问要先确认登录态与后端接口是否就绪，否则前端先用本地存储顶替，后续迁移还是一轮返工。

URL、localStorage、sessionStorage、全局状态怎么挑

这四种是 2026 年 React 项目里比较常见的落点，它们不是竞争关系。实际项目通常是组合使用，下面按经验区间给出一组可核对对比，具体仍以项目实际为准。

• URL 查询参数：适合可分享、可后退、可被搜索引擎抓到内容变体的场景；常见做法是长度控制在 2000 字符以内更稳妥，敏感字段不能放。
• localStorage：适合跨会话保留的轻量偏好，如主题、语言、同类目；同步 API，容量常见 5MB 量级，同一浏览器多标签页会互相影响。
• sessionStorage：适合单标签页内的临时恢复，比如填了一半的表单；关掉标签页即失效，多端表现不一定一致。
• 全局状态（Context 或状态库）：适合跨组件共享的当前会话数据；刷新即丢，不应被当成持久层来用。

一个比较务实的组合是：URL 承载用户看得见的筛选与分页，本地存储承载用户偏好，全局状态承载已经请求回来的数据，三者通过一个统一的取数函数收口，避免每个组件各自去读存储、各自定义兜底逻辑。经验区间上，后台列表页做 URL 同步，通常涉及列表、详情返回、分页三处改动，常见区间是半天到一天；如果同时要兼容多端分享与非法参数兜底，可能再多半天。

一次筛选条件丢失带来的返工

有个后台列表页，需求只写了“支持多条件筛选”。开发时筛选条件放在组件 state 里，自测没问题。上线后反馈：把筛好的链接发给同事，对方打开是全部数据。当时的约束是交付周期只剩两天、后端接口不支持保存筛选。按企业项目交付习惯，我们改成把筛选条件同步到 URL 查询串，保留可读的字段名，进入页面时用查询串初始化状态，并对非法值做兜底。代价是列表页、详情返回、分页三处都要跟着改，经验区间大约半天到一天的返工量，比一开始就想清楚存放位置多花了不少时间。

验收时看什么，以及适用边界

位置放对只是第一步，能不能交付还要看几个可核对的点。合格的标准不是“我测过能刷新”，而是关掉标签、复制链接、后退几次之后，页面仍然回到用户预期的那一屏。

• 刷新后：筛选、分页、Tab 选中态回到原位，且不触发重复请求。
• 复制链接：在新窗口打开，内容与复制时一致；涉及权限的数据不应出现在 URL 里。
• 后退前进：浏览器后退不会把页面打回默认状态。
• 存储读取：值被手工改坏时页面要有兜底，而不是直接白屏。
• 多标签：同一份本地存储被两个标签同时写入时，行为可预期、不互相踩。

高频坑集中在三处：一是把手机号、token 之类敏感字段写进 URL，转发链接就等于泄露；二是本地存储里存了对象却没版本号，字段改名后旧数据解析失败；三是只在组件挂载时读一次存储，用户后来改了偏好，页面不跟着变。

适用边界方面：这套判断在需要分享、复现、跨会话记忆的页面上收益明显，尤其是后台列表、筛选页、多步表单和带 Tab 的内容页。反过来，一次性活动页、纯展示落地页，以及对话式界面里只在内存中滚动的内容，强行往 URL 上塞反而会让链接又长又乱，并不值得做。另一条边界是安全：凡是和身份、权限、金额有关的状态，都不该由前端存储来决定最终结果，前端存储只做展示层的记忆，判定必须回到服务端。需要依据时，可按平台官方文档和团队验收清单核对具体参数格式与容量限制。

常见问题

刷新后状态全丢，是 React 的问题吗？

不是。React 组件 state 本来就只活在内存里，刷新重建组件树就会清零，想留住得放到 URL 或本地存储。

把筛选条件放 URL，会影响前端 SEO 吗？

通常不会，反而利于搜索引擎抓到内容变体。注意别让同一内容产出大量无意义参数组合，必要时用 canonical 收口。

localStorage 和 sessionStorage 到底选哪个？

关掉标签页还要留的用 localStorage；只在当前标签内临时恢复的用 sessionStorage。需要跨设备的，两者都满足不了。

状态要不要直接塞进全局状态库？

全局状态解决的是跨组件共享，不是持久化。刷新即丢的特性没变，需要长久保留的仍要落到 URL 或存储层。

涉及金额或权限的状态能放本地存储吗？

不建议把判定依据放前端存储。前端存储只做展示层记忆，最终以服务端返回为准，避免被手工改坏后影响权限。

如果你的页面存在刷新丢状态、链接不可复现，先按“三问定位置”把字段逐个过一遍，再统一 URL 参数命名与非法值兜底规则，写进验收清单。这套做法适合有分享与复现需求的页面；一次性活动页与纯展示页可以只做最简单处理。涉及权限与金额的数据，前端存储只负责记忆，判定仍以服务端为准。