recoil怎么用？我用筛选页测了一遍
recoil怎么用，光看 API 示例很容易觉得“会了”，真正上手后才会遇到 atom 拆分、selector 依赖、异步错误和 URL 同步。我用一个商品筛选页做了完整体验：从安装和包裹 RecoilRoot，到输入条件、生成参数、读取结果，再把几种常见写法放在一起对比，告诉你哪些顺、哪些别急着用。
1. 状态放 useState，还是放 atom？
我先做了一个本地筛选栏：搜索词只在筛选组件里使用，直接 useState 最舒服，代码短，状态生命周期也清楚。后来顶部结果数、导出按钮和列表空状态都要读取搜索词，这时继续层层传 props 就开始别扭，我才把 searchText 抽成 atom。
实测感受是，atom 适合“多个不相邻组件都要用”的值，不适合把每个输入框都全局化。一个只服务于单个弹窗的临时值放进 Recoil，收益很小，反而增加了 key 和默认值管理。
2. 直接读 atom，还是用 selector 组合？
如果组件只需要一个状态，我用 useRecoilValue 直接读 atom；如果要写入，则根据需求选 useRecoilState 或 useSetRecoilState。后者在按钮组件里很实用，因为它不会订阅当前值，职责更单一。
当接口需要 keyword、category 和库存状态组合时，我没有在列表组件里手动拼对象，而是建了一个 selector。这样参数逻辑集中，任何读取它的地方都拿到同一套结果。代价是排查问题时要沿着 selector 依赖往回看，命名必须足够具体。
3. 异步 selector，还是请求库？
我试过用 selectorFamily 根据商品 ID 读取详情，演示效果很漂亮：组件读取参数化 selector，数据加载交给 Suspense。但一旦加入接口失败、手动刷新和旧数据保留，代码马上需要更多边界处理。
所以在实际页面里，我把 Recoil 留给筛选条件，把请求交给数据请求库。这个组合比“所有东西都放 selector”更稳：Recoil 管用户正在怎么筛，Query 层管服务器返回什么。两者职责分开后，缓存失效和页面草稿不再互相打架。
4. 持久化和性能：好用，但不是自动发生
筛选条件要在刷新后保留，我最后选 URL 同步，而不是直接写 localStorage。URL 更适合可分享、可返回的筛选页；localStorage 适合用户偏好。无论选哪种，都要处理首次初始化、类型转换和清空逻辑，不能把字符串直接当数字用。
性能上，Recoil 的按节点订阅确实让局部更新更自然，但它不会替你修复大数组、昂贵计算或不稳定 selector。我的经验是先看组件是否订阅了过大的对象，再看派生计算是否能拆分，别一上来就靠“状态库优化”四个字自我安慰。
常见问题
- recoil怎么用，第一步需要做什么？
- 安装 Recoil 后，用 RecoilRoot 包住需要访问状态的组件树，再定义带唯一 key 和默认值的 atom，组件通过 Recoil hooks 读取或修改。
- useRecoilState和useRecoilValue有什么区别？
- useRecoilState同时返回当前值和更新函数；useRecoilValue只读当前值。只负责触发修改时，可用 useSetRecoilState，减少不必要的订阅。
- Recoil状态刷新页面会消失吗？
- 默认会消失。要保留状态，需要自行同步到 URL、localStorage 或后端，并处理初始化时的恢复、数据格式和过期策略。