recoil对比实战：后台筛选页为何换掉Redux
recoil对比不能只看代码行数，真正要看状态怎么流动、谁负责请求、出了问题能不能定位。本文复盘一个商品运营后台从 Redux 迁移到 Recoil 的全过程：为什么动手、迁移了哪些模块、哪里变快、哪里反而更麻烦。你会看到一个真实项目里的取舍，而不是“某方案全面碾压”的结论。
问题：一个筛选页，为什么越改越重？
案例是一个 React 商品运营后台，页面包含品牌、类目、库存、价格区间和日期筛选。原先所有条件都放在 Redux 的一个 filter slice 里，列表请求、导出按钮、URL 同步和顶部统计都订阅它。看起来集中，实际改一个价格输入框，整个页面不少区域都会跟着更新。
团队最初并不是为了追求更少代码，而是想把“筛选条件”和“列表结果”拆开。筛选条件是页面交互状态，商品列表是服务端数据，二者混成一个 slice 后，清空筛选、请求失败和旧数据保留等逻辑互相缠绕。
问：为什么最后选 Recoil，而不是继续拆 Redux？
答：当时页面里有多个局部状态组合，Recoil 的 atom 依赖关系更贴近页面结构。团队把 brandId、categoryId、stockStatus 分成独立 atom，再用一个 selector 组合出请求参数；组件按需订阅，不必为一个大对象变化全部重算。
但这不是性能测试后的绝对胜利。Redux 已有成熟 DevTools、action 日志和团队经验，迁移后 Recoil 的调试路径反而没那么统一。最终只迁移页面筛选和编辑草稿，登录用户、权限和跨页面流程仍保留原方案。
问：具体怎么迁移，哪些地方最容易出错？
答：第一步先建立 RecoilRoot，第二步把原 slice 拆成稳定的 atom，第三步用 selector 生成接口参数，最后才改组件读取方式。迁移过程中没有一次性替换请求层，而是让旧 Redux action 和新 atom 暂时并存，通过一个同步适配层逐步切流。
最麻烦的是 URL 同步。浏览器返回会改变筛选条件，用户输入也会改 URL，如果两边互相监听，很容易形成循环更新。项目最后只保留一个写入入口：初始化时 URL 写入 atom，交互变化再由防抖后的 effect 更新 URL。
结果：局部更新更清楚，但维护风险上升
上线后，筛选输入的局部重渲染减少，组件代码也更容易看出“这个组件依赖哪些条件”。清空筛选不再需要构造一整套 Redux action，页面体验更顺。代价是团队需要额外约定 atom 命名、默认值和 selector 层级，否则状态会从一个大文件变成很多小文件，搜索成本反而变高。
复盘结论很克制：Recoil 解决了这个页面的状态粒度问题，却没有替代请求缓存、权限流转和调试体系。更重要的是，Recoil 仓库已于 2025 年归档，新项目要把长期维护因素放在对比表里，而不是只看迁移后的短期手感。
常见问题
- Recoil 对比 Redux，代码一定更少吗？
- 不一定。局部状态和派生状态通常更简洁，但复杂调试、持久化、URL同步和团队规范仍要自己建设，项目越大越不能只看文件数量。
- Recoil 能和 Redux 同时使用吗？
- 可以。常见做法是让 Redux 管全局流程或旧模块，Recoil 管新页面的局部交互状态，但要明确数据归属，避免两边保存同一份可变数据。
- 迁移 Recoil 时应该先改什么？
- 先画出状态依赖图，再迁移低风险的筛选、弹窗、编辑草稿，最后处理权限、路由和服务端缓存，不要一开始就重写整个 store。