React Router 中 useSearchParams 与 useBlocker 的联动问题解析

问题背景

在 React Router v6 的使用过程中，开发者发现当结合 useSearchParams 和 useBlocker 两个 Hook 时，会出现 URL 查询参数状态不一致的问题。具体表现为：当用户尝试修改查询参数并取消导航时，useSearchParams 返回的值会错误地反映被阻止的修改，而不是当前实际 URL 中的值。

技术细节分析

useBlocker 的工作原理

useBlocker 是 React Router 提供的一个 Hook，用于阻止或拦截导航行为。它接收一个回调函数，该函数可以决定是否阻止即将发生的导航。当导航被阻止时，URL 实际上不会发生变化，但应用内部的状态可能会提前更新。

useSearchParams 的行为

useSearchParams 返回一个包含当前 URL 查询参数的状态和更新函数。在理想情况下，它应该始终反映当前 URL 的实际状态。然而，在与 useBlocker 结合使用时，出现了状态不同步的问题。

问题复现场景

1. 组件中使用 useSearchParams 获取当前查询参数
2. 通过按钮点击等交互更新查询参数
3. useBlocker 拦截这次导航变更并显示确认对话框
4. 用户选择取消导航
5. 此时 useSearchParams 返回的值是被阻止的"新值"，而不是应该保持的"旧值"

根本原因

这个问题源于 React Router 内部状态管理的时序问题。当查询参数更新时：

1. useSearchParams 的内部状态立即更新
2. useBlocker 拦截导航并阻止 URL 实际变化
3. 但 useSearchParams 的状态没有被回滚，导致与真实 URL 不同步

解决方案与最佳实践

临时解决方案

目前可行的临时解决方案包括：

1. 直接使用 useLocation 获取查询参数，通过 URLSearchParams 解析
2. 在取消导航时手动重置 useSearchParams 的状态

长期建议

对于需要精确控制导航和状态同步的场景，建议：

1. 将查询参数状态提升到组件状态或全局状态管理
2. 实现自定义的同步逻辑，确保 URL 和状态的一致性
3. 考虑使用 React Router 的稳定版本更新，关注官方修复进展

总结

这个问题揭示了前端路由库中状态同步的复杂性。开发者在使用导航拦截功能时，需要注意它可能带来的副作用，特别是与 URL 相关状态 Hook 的交互。理解这些底层机制有助于构建更健壮的前端导航逻辑，避免出现状态不一致的边界情况。