使用Redux-Thunk时，在action creator中用getState()取用户ID是否合理？

好问题！其实在你的这个场景里，用getState()获取userId是完全可行且合理的，不过两种实现方式也各有适用场景，咱们来具体拆解：

你的当前做法为什么合理 #

• 你的userId属于全局认证状态的一部分，是Redux Store中存储的共享核心数据。在action creator里通过getState()直接获取，能让组件和action的耦合度更低：组件只需要调用getUserHobbies()来触发获取爱好的逻辑，不需要关心背后需要userId这个细节，也不用在每个调用的地方都手动传递这个参数。
• 你当前的代码写法也很规范：先通过getState()拿到userId的快照并保存，避免了后续异步过程中状态变化导致的不一致问题，这是正确的处理方式。

什么时候适合从组件传入userId #

如果你的业务逻辑有扩展需求，比如这个action不仅要获取当前登录用户的爱好，还需要支持获取其他用户的爱好（比如查看他人资料页的场景），这时候把userId作为参数传入action creator会更灵活：

export const getUserHobbies = (userId) => (dispatch) => { 
  dispatch({ type: GET_HOBBIES_REQUEST }); 
  return fetch(`api/hobbies/?userId=${userId}`) 
    .then(json => { /* ... */ }) 
    .catch(e => { /* ... */ }) 
};

这种方式下，action creator的复用性更强，能适配更多场景。

额外的测试与实践提示 #

• 不用担心测试问题：测试Thunk函数时，你可以轻松mockgetState函数，返回预设的userId值，完全能覆盖测试场景。
• 避免过度依赖getState()：如果你的action需要依赖多个分散的state片段，或者依赖的状态和当前action的关联性不强，这时候可能需要重新考虑状态结构，或者通过组件传参来让逻辑更清晰，但你的场景显然不属于这种情况。

总的来说，你当前的实现没有问题，完全符合Redux-Thunk的设计意图。如果你的业务始终只需要获取当前登录用户的爱好，保持现在的写法就很好；如果未来有扩展需求，再调整为组件传参的方式也不迟。

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