React/Node/Express下带userID参数的Redux数据拉取异常排查

1. 最致命的结构错误：异步Thunk的生命周期reducers放置位置错误 #

• createSlice的reducers字段仅用于定义同步状态修改逻辑，框架会为这些逻辑自动生成对应action creator。
• 针对createAsyncThunk生成的pending/fulfilled/rejected生命周期action，必须放入extraReducers字段中，框架才会将对应处理逻辑绑定到全局store的监听链路。
• 你当前的写法把thunk生命周期的处理逻辑写在了普通reducers字段里，框架根本不会识别这些自定义的action类型和对应处理逻辑的关联。这也完全匹配你观察到的现象：请求能正常发出、后端能收到正确的userID参数，但是响应回来后dispatch的fulfilled action根本不会触发store更新，前端永远拿不到返回数据。

2. condition拦截逻辑存在设计缺陷 #

• 你之前怀疑的状态路径读取不匹配的问题其实不存在：从getState中读取user分支的路径是完全正确的。但这个逻辑本身存在两个问题：
  1. 当前的condition函数仅写了拦截分支：如果user.didLoadData为true就返回false阻止请求，没有显式的放行逻辑（虽然JS中无返回值等同于undefined，默认会放行请求，但是逻辑不严谨）。
  2. didLoadData状态没有和当前拉取的userID做关联：哪怕后续把reducers位置改对，只要任意一次触发拉取，pending阶段就会把didLoadData标记为true，后续切换任何用户ID都会被condition直接拦截，根本无法实现按用户维度加载日志的需求。正确的做法是缓存当前已加载的userID，判断传入的userID是否和缓存的一致，再决定是否拦截。
• 也正是因为pending的处理逻辑放错了位置，didLoadData永远停留在初始的false值，所以condition从来不会触发拦截，请求能正常发出，这和你观察到的“后端收到携带正确userID的请求”的现象完全吻合。

3. fulfilled状态的payload处理存在结构错位风险 #

• 你当前的fulfilled逻辑是直接展开action.payload到state上，需要和后端返回结构严格对齐：
  • 如果后端返回结构是{ userDiveLogList: 日志数组 }，展开操作可以正确覆盖对应字段；
  • 如果后端返回的res.data就是日志数组本身，那对数组做展开操作只会把索引、length等数组内置属性挂到state上，根本不会给state.userDiveLogList赋值，状态里的日志列表永远是空值。

4. 组件层数据绑定逻辑断裂 #

• 你通过useSelector从redux中拿到了state.user.userDiveLogList，但是同时用useState定义了一个本地userDiveLog状态，初始值包含空的userDiveLogList，后续从来没有通过setUserDiveLog把redux更新的日志列表同步到本地状态。如果你的UI渲染绑定的是这个本地useState中的日志列表，哪怕redux状态更新正确，界面也永远显示初始的空数组。
• 另外useEffect的依赖数组为空，但是内部使用了user.userID：如果userID是登录后异步获取的，组件首次挂载时dispatch的可能是空值，后续userID更新后根本不会重新触发拉取。

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