项目中useDispatch、bindActionCreators放置位置及Redux文件结构如何设计？

一、useDispatch、bindActionCreators 定位与 containers 方案合理性 #

你当前重复编写的导入、绑定逻辑属于冗余代码，完全可以通过封装简化，没必要每个组件都重复实现一遍：

• 首先要明确：现在已经不推荐手动调用 bindActionCreators 做绑定，常规使用场景下，直接在组件中调用 dispatch 包裹 action creator 即可，示例如下：

import { useDispatch } from "react-redux";
import { fetchStats } from "@/features/stats/statsSlice";

// 组件内逻辑
const dispatch = useDispatch();
// 调用时直接传入 action 执行结果即可
dispatch(fetchStats(params))

• 如果你还是习惯使用已经绑定好的 action 方法，可以封装一个公共自定义 Hook 统一处理逻辑，所有组件直接调用 Hook 即可，不需要重复写导入和绑定代码：

// hooks/useActions.js
import { useDispatch } from "react-redux";
import { bindActionCreators } from "redux";
import * as statsActions from "@/features/stats/statsSlice";
import * as userActions from "@/features/user/userSlice";

const allActions = {
  ...statsActions,
  ...userActions
}

export default function useActions() {
  const dispatch = useDispatch();
  return bindActionCreators(allActions, dispatch);
}

// 组件内使用
import useActions from "@/hooks/useActions";
const { fetchStats } = useActions();
// 直接调用即可
fetchStats(params)

关于 containers 文件夹的方案：这是 React class 组件时代的标准实践，也就是「容器组件/展示组件分离」模式，容器组件专门负责和 Redux 交互、处理数据逻辑，展示组件只负责接收 props 渲染。这套方案本身没有问题，但是在函数组件+Hooks 成为主流之后，已经不需要单独维护 containers 层，Redux 的关联逻辑可以直接写在业务组件内部，代码更简洁。如果你的团队已经习惯这套分离模式，继续使用也完全合理。

二、Redux 文件结构最佳实践 #

你提到的所有 action 放在同一个文件的方案，确实只适合小型 Demo 或者超小型项目，大型项目维护成本极高。目前官方推荐的是按业务功能/模块组织代码的结构，不要按文件类型（action/reducer/selector）拆分：

推荐结构（搭配 Redux Toolkit，官方标准方案） #

src/
├── app/
│   ├── store.js  // 全局 store 配置
├── features/  // 所有业务模块都放在这个目录下
│   ├── statistics/  // 统计业务模块
│   │   ├── statisticsSlice.js  // 单个 slice 自动包含 action 类型、action creator、reducer 逻辑，不需要单独写 action 文件
│   │   ├── statisticsSelectors.js  // 该模块的查询函数
│   │   ├── StatisticsPage.jsx  // 该模块的业务组件
│   ├── user/  // 用户业务模块
│   │   ├── userSlice.js
│   │   ├── userSelectors.js
│   │   ├── UserProfile.jsx
├── hooks/  // 公共自定义 Hook
├── components/  // 全局公共组件

优化点说明： #

• 不需要单独维护 action 文件：使用 Redux Toolkit 的 createSlice API，会自动根据你写的 reducer 函数生成对应的 action creator，直接从 slice 文件导出即可，不需要手动写 action 类型常量、action 创建函数，减少70%的冗余代码。
• 按业务模块聚合代码：修改某一个业务逻辑时，只需要进入对应模块的文件夹即可找到所有相关代码，不需要在不同的 actions、reducers 文件夹来回跳转，大型项目维护效率提升非常明显。
• 如果你的项目暂时没有用 Redux Toolkit，还是用原生 Redux 写法，也可以参考这个按模块组织的思路，每个业务模块单独放自己的 action、reducer 文件，不要把所有 action 都塞到同一个全局 action 文件里。

内容的提问来源于stack exchange，提问作者user15505770