从设计原则和实际执行机制两个层面分析：在 Redux 的 reducer 内部调用 dispatch 是否被推荐？请说明原因及背后的设计考量。
考察说明
考察对 Redux 单向数据流和纯函数 reducer 设计原则的理解。
回答思路
- 【回答框架 1】Redux 要求 reducer 必须是纯函数，即给定相同的输入（state 和 action）必然返回相同的新 state，且不产生副作用。若在 reducer 中触发 Action，会产生副作用，破坏纯函数性质，导致状态更新不可预测，也可能引发无限循环或重复执行。
- 【回答框架 2】Redux 数据流是单向的：UI 触发 dispatch，reducer 同步执行并返回新 state，然后通知订阅者。reducer 内部 dispatch 会打破这个流程，使得状态更新逻辑复杂化，难以追踪调试。
- 【回答框架 3】如果需要根据当前状态或业务结果再触发其他 Action，应在组件（如使用 useEffect 监听状态变化）或中间件（如 thunk、saga）中处理，而不是在 reducer 中。Reducer 只负责计算下一个状态，不负责副作用或调度。
- 【回答框架 4】官方文档明确不建议在 reducer 中调用 dispatch，原因是 reducer 必须是纯函数，且必须保持可预测性。这也是 Redux 设计核心原则之一。
- 【关键点 1】reducer 必须是纯函数，dispatch 是副作用，两者冲突。
- 【关键点 2】reducer 中 dispatch 会导致状态更新不可预测，可能引发无限循环。
- 【关键点 3】副作用应放在组件、中间件或事件处理中，而不是 reducer。
- 【易错点 1】不要误以为 reducer 中 dispatch 可以实现类似级联更新的效果，这是反模式。
- 【易错点 2】避免在 reducer 中调用非纯函数（如 Date.now、Math.random），它们也会导致状态不可预测。
- 【易错点 3】不要将异步操作放在 reducer 中，Redux 的 reducer 是同步纯函数。