Redux 与 Flux

• createApi 定义端点与自动 hooks
• 缓存、失效与标签机制
• 与 Redux store 集成

RTK Query 是 Redux Toolkit 内置的数据获取与缓存方案，通过 createApi 定义端点（query/mutation），自动生成对应的 hooks（useQuery/useMutation）、缓存管理、请求状态（pending/error/success）。它与 Redux store 深度集成，查询状态存入 store，支持 tags 机制：mutation 成功后按 tag 自动使相关查询失效。工程价值：减少手写 thunk/action/reducer，统一数据获取与全局状态，缓存可观测、可调试，支持乐观更新、轮询、条件请求。

RTK Query 把"服务端状态管理"纳入 Redux 生态，用声明式 API 替代手写异步逻辑。tags 机制实现数据变更后的自动失效与刷新，是它的核心价值。

• createSlice 的集中式 state/reducer/action
• createAsyncThunk 的异步状态流转
• 大型状态的可维护性

createSlice 把 state、reducers、actions 集中定义，自动生成 action creators，reducer 是纯函数配合 Immer 简化不可变更新。createAsyncThunk 封装异步流程，自动生成 pending/fulfilled/rejected 三种 action，简化异步状态管理。工程价值：代码集中在 slice 中、可搜索、可测试；异步逻辑结构化，状态流转清晰；减少样板代码，提升大型应用的开发效率与可维护性。

createSlice 解决"组织"，createAsyncThunk 解决"异步"。两者让大型状态管理从零散 action/reducer 演变为集中、模块化、可测试的 slice 结构。

• createApi 定义基础 API
• injectEndpoints 按模块注入端点
• 模块化与代码拆分

createApi 定义 API 的基座（reducerPath、baseQuery、tagTypes），injectEndpoints 允许在多个模块中按需注入端点，实现 API 的模块化拆分。每个模块用 injectEndpoints 添加自己的 query/mutation，与 createApi 共享同一缓存与标签体系。工程价值：支持大型应用的代码拆分与按需加载，避免把全部端点集中在一个文件；不同团队可独立维护各自端点，仍共享统一的缓存与失效机制。

injectEndpoints 是"模块化注入端点"。它让 API 定义分散到各个模块，同时保持缓存的统一，是大型应用扩展 API 的关键机制。

• listenerMiddleware 监听 action 触发副作用
• 与 thunk/saga 的对比
• 副作用管理的工程化

listenerMiddleware 是 RTK 提供的副作用中间件，可监听特定 action 或条件，触发副作用（请求、导航、持久化）。相比 thunk（手写 action 函数）与 saga（生成器/复杂副作用），listenerMiddleware 用声明式监听器处理副作用，API 更简洁、可取消、支持条件。工程价值：把"某 action 后做什么"集中在中间件，跨组件复用，可测试，替代部分 saga/thunk 场景，降低复杂度。

listenerMiddleware 是"action 驱动的副作用"模型。它保留 thunk 的简单，增加 saga 的监听能力，是副作用管理的轻量现代方案。

• 缓存与数据复用
• 失效与重新获取
• 与全局状态的关系

RTK Query 把服务端数据缓存到 Redux store，同一 queryKey 的查询被多个组件使用时共享缓存，避免重复请求。缓存能力包括：按参数缓存、stale 判断、invalidateTags 失效、refetch 重取、乐观更新、轮询。它把"服务端状态"作为一等缓存管理，与本地 UI 状态分离。工程价值：自动缓存、数据一致、失效机制完善，减少手写请求与缓存逻辑。

RTK Query 作为服务端缓存的核心是"缓存 + 失效 + 复用"。它把带缓存的数据获取标准化，让服务端状态管理可观测、可维护。

• FSA 的 type/payload/meta/error 结构
• 统一 action 形态
• 大型团队的协作与工具链

FSA 规定 action 是 { type, payload, meta, error } 的扁平结构，type 为字符串标识，payload 为数据，meta 为附加信息，error 标识错误。统一 action 形态让大型团队易于协作：action 可预测、可序列化、可测试，工具链（日志、DevTools、中间件）能统一处理。工程价值：降低团队成员对 action 命名的随意性，提升 code review 与调试效率，配合 createSlice 自动生成符合 FSA 的 action。

FSA 的价值是"action 的标准化"。统一结构让 action 可被通用工具消费，是大型团队协作与生态兼容的基础。

• observable 状态与衍生
• 自动追踪依赖
• 与 React 的集成

MobX 用 observable 包装状态，computed 定义派生值，autorun/reaction 实现副作用。读操作被自动追踪依赖，写操作触发相关依赖更新，实现细粒度响应式。它通过观察者模式自动更新依赖的组件，无需手动 selector。与 React 集成用 observer 包裹组件，组件自动订阅其读取的 observable。工程价值：用最少的样板代码实现响应式状态，适合状态关系复杂、衍生多的场景。

MobX 的核心是"可观察 + 自动追踪"。基于 Proxy 的 observable 在 get 时收集依赖、set 时通知，实现透明的响应式更新。

• createSelector 的输入/输出选择器
• 结果缓存与引用稳定
• 缓存键的命中策略

createSelector 组合多个输入选择器，只有当输入变化时才重新计算输出，结果被缓存，保证引用稳定，避免组件因新引用重渲染。缓存键是输入参数，输入组合变化才触发重算，否则返回缓存结果。工程取舍：合理拆分子选择器提升缓存命中率；输入过多或变化频繁时缓存失效，需权衡计算成本与缓存粒度；避免在 selector 内做副作用。

reselect 的价值是"派生数据缓存 + 引用稳定"。缓存键由输入决定，精巧的拆分让缓存命中率最大化，减少不必要重渲染。

• DevTools 记录 action 与状态快照
• 时间旅行（回退/前进）
• action replay 调试

Redux DevTools 记录每个 action 及对应的状态快照，实现时间旅行调试：可回退到历史状态、前进到未来状态，观察状态如何演变。action replay 允许重新触发某个 action 或修改后重放，用于复现与验证。工程价值：状态变更可追溯、可复现，大幅提升 bug 定位与逻辑验证效率。生产环境需禁用。

时间旅行依赖 reducer 的纯函数性——给定状态与 action 总能得到确定性结果。DevTools 因此可任意回放历史，是 Redux 可预测性的重要体现。

• 中间件链与 dispatch 增强
• 副作用与 reducer 隔离
• 中间件的可组合性

Redux 中间件包裹 dispatch，形成中间件链，可在 action 到达 reducer 前/后进行拦截、转换、延迟或发起副作用。副作用被隔离在中间件中，reducer 保持纯函数，保证状态可预测。中间件可组合、可复用（如 thunk、saga、listenerMiddleware）。工程价值：日志、异步、路由导航等副作用集中管理，不污染 reducer，增强 dispatch 而不改变其接口。

中间件是"dispatch 的装饰器"。它把副作用从 reducer 中抽离，通过 compose 组合成链，是 Redux 扩展性的基石。

• combineReducers 的切片组合
• slice 划分边界与跨 slice 依赖
• 大型 store 的组织演化

combineReducers 把多个 reducer 组合成单一 root reducer，每个 reducer 管理自己的状态切片（slice）。划分边界：按业务领域/模块划分，尽量内聚独立，避免强耦合。跨 slice 依赖时，一个 reducer 不能直接读取其他 slice 状态，需通过 action 或 root reducer 协调，或把共享逻辑抽到 selector。大型 store 演进：从单一 reducer 拆分到切片，再配合 RTK、动态注入、代码分割，保持可维护性。工程价值：切片化让状态模块化、可独立测试、可扩展。

slice 划分是"单一职责"原则。边界清晰、依赖可控时，combineReducers 提供清晰的组织；跨 slice 依赖需通过 action 编排或 selector 组合，避免 reducer 间直接耦合。

• 生产环境禁用 DevTools
• 数据泄露与性能风险
• 条件启用策略

生产环境禁用 DevTools 是安全策略：DevTools 会记录完整状态与 action，可能泄露敏感数据，且日志记录有性能开销。策略：通过环境变量（如 NODE_ENV）条件启用，仅开发环境加载；使用 Redux DevTools 的 composeWithDevTools 封装，仅 dev 下启用；或构建时剔除相关代码。工程价值：保护敏感状态、减少内存与性能开销、避免状态可被外部篡改。

生产禁用 DevTools 是"安全 + 性能"的权衡。条件编译让开发体验不损失，同时保证生产环境数据安全与性能。

• makeObservable 显式声明
• makeAutoObservable 自动推导
• class 组件的响应式集成

MobX 6 中 makeObservable 显式声明可观察属性、computed 与 action，makeAutoObservable 自动推导所有属性为 observable、getter 为 computed、方法为 action。两者让 class 组件的字段与方法自动响应式。配合 observer 包裹，class 组件读取的 observable 变化时自动重渲染。工程价值：以 class 的直觉模型管理状态，减少样板代码，适合偏好面向对象风格的团队。

makeAutoObservable 是"零样板响应式"。它自动识别可观察、计算与动作，class 组件与响应式状态结合，更新透明。

• Flux 的 action/dispatcher/store/view
• 单向数据流原则
• 对 Redux/Zustand 等的影响

Flux 提出单向数据流：view 派发 action，dispatcher 分发，store 响应并更新状态，view 订阅 store 重新渲染。数据只能单向流动，状态变更可预测、可追踪。Redux 是 Flux 的简化演化（单一 store、纯 reducer、无 dispatcher），Zustand/Jotai 等沿用单向数据流思想但更轻量。现代状态库继承了 Flux 的"状态变更可预测、可调试"核心，同时减少样板代码。工程价值：单向数据流保证状态变更可追踪，是可靠状态管理的基础。

Flux 的价值是"单向数据流原则"。它约束了状态变更的路径，使状态可预测、可调试，这一原则被几乎所有现代状态库继承。

• Redux 的可预测性来源
• 团队规模与成本收益
• 何时适合 Redux

Redux 的可预测性来自单一 store、纯 reducer、不可变更新与单向数据流，状态变更可追溯、可调试。团队规模匹配：大型团队/复杂应用时，Redux 的约束与工具链带来收益（统一约定、可测试、DevTools）；小型团队/简单应用时，Redux 的样板代码与复杂度可能成为负担。取舍：需要强一致性、多人协作、复杂状态时适合 Redux；简单场景用轻量方案更划算。

Redux 的可预测性以"样板成本"为代价。团队规模越大、状态越复杂，约束的收益越明显；规模小时应避免过度设计。

• Immer 的 draft 可写语义
• createSlice 的自动 Immer
• 不可变更新简化

RTK 的 createSlice 内置 Immer，reducer 中可像"可变"一样直接修改 draft（如 state.x = 1、push），Immer 自动产出不可变新状态。这避免手写展开运算符（...state）与深拷贝，降低出错概率。Immer 通过 Proxy 记录对 draft 的修改，生成新的不可变对象。工程价值：让不可变更新写起来简单直观，同时保持不可变性带来的可预测性与引用优化。

Immer 是"可变语义 + 不可变结果"。它让 reducer 的写法更安全、更简洁，是 RTK 降低样板代码的关键。

• normalized state 的扁平化存储
• 实体关系与引用
• 嵌套状态的取舍与 selector 重组

规范化状态把实体按 id 扁平存储（如 { users: {byId}, posts: {byId} }），关系用 id 引用，避免嵌套状态中的重复数据与更新困难。取舍：嵌套状态直观但更新深层字段需深拷贝、易产生重复；规范化状态更新单一实体、避免重复，但需 selector 重组为视图结构。工程价值：更新一处全局生效、数据一致、便于关联查询；用 reselect 的 createSelector 把扁平数据重组为嵌套视图。

规范化是"数据存储与视图解耦"。存储按实体扁平化便于更新，视图用 selector 重组，兼顾一致性与易用性。