获课：xingkeit.top/16357/

踩坑总结｜React 全家桶 Redux+Antd+Hooks 开发实战经验

过去半年，我带着团队用 React 全家桶（Redux + Antd + Hooks）从零搭了一个中后台管理系统。项目上线后，我花了一整晚把开发过程中踩过的坑、填过的雷整理成这份总结。没有贴代码，只讲思路和教训，希望能帮你在同样的路上少绕几个弯。

状态管理：Redux 的过度设计与“反模式”

第一个大坑来自 Redux。项目初期，我们几乎把所有异步请求的数据都塞进了 Redux，结果 store 越来越臃肿，组件依赖复杂到改一个字段要动三个 reducer。

教训：并非所有数据都值得进 Redux。 我们后来明确了三条边界：只在整个应用生命周期内需要持久化或跨组件共享的数据才进 store，比如用户信息、权限菜单、全局配置；只在单个页面内流转的状态，用 Hooks 自带的 useState 或 useReducer 就够了；表单的临时输入状态，完全交给 Antd 的 Form 实例管理，绝不存 Redux。

另一个致命问题是异步链路过长。 我们早期用 redux-thunk，一个接口调完还要处理 loading、成功、失败三个状态，每个都要手动 dispatch，代码重复率极高。后来切换到 Redux Toolkit，用 createAsyncThunk 一键生成 pending/fulfilled/rejected 生命周期，配合 extraReducers 处理副作用，代码量直接砍掉三分之一。强烈建议新项目直接用 Redux Toolkit，别再手写 action types 和 reducer 了。

表单战场：Antd 的“糖衣炮弹”

Antd 的 Form 组件看起来封装得很完美，但实际用起来处处是暗坑。

最大的坑是表单与 Redux 的双向绑定。 我们最初想把表单值实时同步到 Redux，结果每次输入都触发全局刷新，页面卡顿明显。正确的做法是用 Form 的 onValuesChange 做防抖，只在特定时机（比如点击提交或离开页面）才将有效数据提交给 Redux。

表单验证也踩了不少雷。 自定义校验规则里如果调用了 Redux 的数据（比如校验用户名是否重复），必须用 Form 的 validateFields 手动触发，而不能依赖 rules 里的 async validator，否则会因为闭包问题拿到旧数据。另外，Modal 中的 Form 一定要用 forceRender 或者给 Form 加 key，否则打开弹窗时表单数据不会重置，这个问题我们排查了整整一个下午。

Hooks 的“副作用地狱”

Hooks 确实让逻辑复用变简单了，但用不好就是灾难。

useEffect 的依赖数组是我们出错最多的地方。 特别是依赖了函数或对象时，稍不注意就会陷入无限循环。解决方案是：能用 useCallback 包裹的函数尽量包裹，对象依赖改用 useMemo，实在不行就用 useRef 存一份上一次的值做对比。

自定义 Hooks 的复用边界要清晰。 我们封装了一个 useTable 来管理列表页的分页、筛选、排序，但后来发现不同的列表页逻辑差异很大，强行复用反而让 Hook 变得极其复杂。最终只保留了分页和 loading 的基础逻辑，业务筛选和排序交给各页面自己管理。

一个容易忽视的坑：在 Hooks 里使用 Redux 的 dispatch 时，如果组件被 React.memo 包裹，dispatch 的引用变化会导致 memo 失效。 解决方案是用 useStore 或 useDispatch 的稳定引用，或者直接去掉不必要的 memo。

性能优化：该做和不该做的

中后台项目最容易出现性能问题的是大列表和频繁刷新。

大列表我们用 Antd Table 配合虚拟滚动，但初始渲染依然慢。 后来发现是 columns 定义在组件内部，每次渲染都会重新生成，导致 Table 全量重绘。把 columns 用 useMemo 缓存后，渲染速度提升了近一倍。

不必要的 re-render 是另一个隐形杀手。 我们用了 Reselect 来创建记忆化的 selector，配合 Redux 的浅比较，避免了组件因无关状态变更而刷新。但也要注意，selector 如果返回新对象（比如 filter 后生成新数组），即使数据没变，组件也会因为引用变化而重绘。

项目结构：别让“规范”变成“桎梏”

我们一开始参考了很多开源项目，把代码分成了 pages、components、store、utils、services 等十几个文件夹。但随着项目变大，跨文件夹的引用越来越多，改一个功能要在五六个地方跳转。

后来我们调整为“以功能模块为核心”的结构——每个模块包含自己的页面、组件、样式、hooks 和 store slice。公共部分才抽到全局。这个调整让新成员上手更快，改功能时也能在一个目录下完成大部分操作。

写在最后

技术选型没有绝对的对错，关键是理解每个工具的设计哲学和适用边界。Redux 强在状态可预测和回溯，但用不好就成了枷锁；Antd 胜在组件丰富，但要学会适时跳出它的封装；Hooks 是 React 的未来，但要用好仍需敬畏它的规则。

半年实战下来，最大的感受是：比技术更重要的，是团队的协作习惯和代码审查机制。 再好的架构，也经不起随意堆砌。希望这份踩坑记录能帮你少走弯路，也欢迎在评论区分享你的经历。