redux 中状态更新失败通常源于 reducer 内直接修改了 state 对象，违反了不可变性原则；正确做法是返回全新状态对象，确保 react 和 redux 能正确触发组件重渲染。
在使用 Redux + redux-saga 构建 React 应用时，一个高频陷阱是：Saga 成功 dispatch 了 FETCH_PRODUCTS_SUCCESS action，但 App 组件却未响应状态变化、无法获取最新数据。根本原因往往不在 saga 逻辑，而在于 reducer 的实现方式——尤其是对不可变性的忽视。
❌ 错误写法：直接修改 state（导致状态更新静默失败）
// ❌ 危险！直接赋值修改原 state case FETCH_PRODUCTS_SUCCESS: state.products = action.products; // 修改了原引用，Redux 无法检测到变化 break;
该写法看似简洁，实则破坏了 Redux 的核心契约：reducer 必须是纯函数，且绝不修改传入的 state。由于 state.products = ... 是就地修改（mutation），Redux 的浅比较机制会认为 state 未变，从而跳过组件更新，导致 useSelector 或 connect 无法感知新值。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
✅ 正确写法：返回全新状态对象（符合不可变更新规范）
// ✅ 安全！返回新对象，保持不可变性
case FETCH_PRODUCTS_SUCCESS:
return { ...state, products: action.products };
default:
return state; // 必须为 default 分支显式返回 state- 使用展开运算符 { ...state } 创建 state 的浅拷贝；
- 用新值 action.products 覆盖 products 字段；
- default 分支必须返回 state —— 缺失此行将导致未匹配 action 时返回 undefined，引发整个 Redux store 崩溃。
? 额外检查点（确保端到端生效）
确认 saga 正确 dispatch action
检查 saga 是否调用了 put({ type: FETCH_PRODUCTS_SUCCESS, products })，且 products 数据非空/有效。-
验证 selector 与组件绑定
在 App.js 中确保使用了正确的 selector：const products = useSelector(state => state.productsReducer.products);
-
检查 store 配置与 rootReducer 合并
确保 productsReducer 已正确注入 rootReducer，例如：const rootReducer = combineReducers({ productsReducer // ✅ 命名需与 useSelector 中的 key 一致 }); -
避免常见副作用陷阱
- 不要在 reducer 中执行异步操作、修改 props、调用 API 或使用 Date.now() 等非纯函数；
- 所有状态变更必须通过 action 触发，由 reducer 纯函数响应。
? 总结
Redux 的响应式更新依赖于「状态引用变更」这一信号。任何对 state 的直接赋值（如 state.xxx = yyy）都会切断这一信号链，使组件“失联”于新状态。坚持永远返回新对象、永不修改旧 state，是规避此类问题的黄金法则。配合 Redux DevTools 实时观察 state 变化，可快速定位不可变性违规行为。
