面试题手册

Zustand 的优点：更简单的 API无需定义 action types、reducers、action creators代码量减少 60-70%学习曲线更低无需 Provider不需要在应用顶层包裹 Provider 组件减少了组件树的嵌套层级更容易集成到现有项目中更好的性能内置选择性订阅机制自动优化重渲染无需手动使用 useSelector 或 connect更小的体积仅约 1KB gzippedRedux Toolkit 约 12KB gzippedTypeScript 友好内置完整的 TypeScript 支持类型推断更准确Zustand 的缺点：生态系统较小中间件和扩展库相对较少社区资源不如 Redux 丰富调试工具有限虽然 Redux DevTools 可以使用，但功能不如 Redux 完善时间旅行调试支持有限大型项目经验较少在超大型企业级应用中的实践案例较少最佳实践仍在发展中团队熟悉度开发者对 Redux 更熟悉招聘和培训成本可能更高选择 Zustand 的场景：中小型项目项目规模不大，状态管理需求简单不需要复杂的状态管理架构快速原型开发需要快速搭建和迭代重视开发速度而非架构完整性性能敏感的应用需要最小化重渲染对包大小有严格要求团队偏好简洁团队成员熟悉 hooks 模式希望减少样板代码选择 Redux 的场景：大型企业级应用需要严格的状态管理架构团队规模大，需要标准化流程复杂的状态逻辑需要时间旅行调试状态更新逻辑复杂，需要规范化团队已有 Redux 经验团队成员熟悉 Redux已有相关的工具和基础设施总结：Zustand 更适合现代 React 开发，特别是中小型项目和追求简洁的场景。Redux 更适合大型企业级应用和需要严格状态管理的场景。

MobX 和 Redux 都是流行的状态管理库，但它们的设计理念和使用方式有很大的不同。选择哪一个取决于项目需求、团队偏好和具体场景。核心设计理念MobX基于观察者模式：自动追踪状态变化，无需手动订阅命令式编程：直接修改状态，更符合直觉透明响应式：状态变化自动触发更新灵活性高：不强制特定的代码结构Redux基于函数式编程：使用纯函数处理状态变化声明式编程：通过 dispatch action 来修改状态单向数据流：Action → Reducer → Store → View规范性高：强制特定的代码结构代码对比MobX 示例import { observable, action, computed, makeAutoObservable } from 'mobx';class TodoStore { todos = []; filter = 'all'; constructor() { makeAutoObservable(this); } @computed get filteredTodos() { switch (this.filter) { case 'completed': return this.todos.filter(todo => todo.completed); case 'active': return this.todos.filter(todo => !todo.completed); default: return this.todos; } } @action addTodo(text) { this.todos.push({ id: Date.now(), text, completed: false }); } @action toggleTodo(id) { const todo = this.todos.find(t => t.id === id); if (todo) todo.completed = !todo.completed; } @action setFilter(filter) { this.filter = filter; }}const store = new TodoStore();// 使用store.addTodo('Learn MobX');store.toggleTodo(store.todos[0].id);Redux 示例import { createStore } from 'redux';// Action Typesconst ADD_TODO = 'ADD_TODO';const TOGGLE_TODO = 'TOGGLE_TODO';const SET_FILTER = 'SET_FILTER';// Action Creatorsconst addTodo = (text) => ({ type: ADD_TODO, payload: { id: Date.now(), text, completed: false } });const toggleTodo = (id) => ({ type: TOGGLE_TODO, payload: id });const setFilter = (filter) => ({ type: SET_FILTER, payload: filter });// Reducerconst initialState = { todos: [], filter: 'all'};function todoReducer(state = initialState, action) { switch (action.type) { case ADD_TODO: return { ...state, todos: [...state.todos, action.payload] }; case TOGGLE_TODO: return { ...state, todos: state.todos.map(todo => todo.id === action.payload ? { ...todo, completed: !todo.completed } : todo ) }; case SET_FILTER: return { ...state, filter: action.payload }; default: return state; }}const store = createStore(todoReducer);// Selectorconst selectFilteredTodos = (state) => { switch (state.filter) { case 'completed': return state.todos.filter(todo => todo.completed); case 'active': return state.todos.filter(todo => !todo.completed); default: return state.todos; }};// 使用store.dispatch(addTodo('Learn Redux'));store.dispatch(toggleTodo(store.getState().todos[0].id));详细对比| 特性 | MobX | Redux ||------|------|-------|| 编程范式 | 命令式、面向对象 | 函数式、声明式 || 状态追踪 | 自动追踪 | 手动订阅 || 状态修改 | 直接修改 | 通过 action || 代码量 | 较少 | 较多 || 学习曲线 | 平缓 | 陡峭 || 灵活性 | 高 | 低 || 规范性 | 低 | 高 || 调试工具 | MobX DevTools | Redux DevTools || 时间旅行 | 有限支持 | 完整支持 || 中间件 | 不需要 | 丰富（redux-thunk、redux-saga 等） || 性能 | 自动优化 | 需要手动优化 || 状态结构 | 可以嵌套 | 推荐扁平化 || 类型支持 | 良好 | 需要额外配置 |使用场景适合使用 MobX 的场景快速开发：需要快速原型开发或小型项目复杂状态结构：状态结构复杂且嵌套团队经验：团队更熟悉面向对象编程灵活性优先：需要更多的代码灵活性学习成本：希望降低学习成本// MobX 适合复杂嵌套状态class UserStore { @observable user = { profile: { name: '', email: '', address: { city: '', country: '' } }, preferences: { theme: 'light', language: 'en' } }; @action updateCity(city) { this.user.profile.address.city = city; // 直接修改嵌套属性 }}适合使用 Redux 的场景大型项目：需要严格规范的大型项目团队协作：多人协作，需要统一的代码规范时间旅行：需要完整的时间旅行调试功能中间件需求：需要使用丰富的中间件生态函数式编程：团队偏好函数式编程范式// Redux 适合扁平化状态const initialState = { users: { byId: {}, allIds: [] }, profiles: { byId: {}, allIds: [] }, addresses: { byId: {}, allIds: [] }};// 通过 reducer 处理状态变化function reducer(state = initialState, action) { switch (action.type) { case UPDATE_CITY: return { ...state, addresses: { ...state.addresses, byId: { ...state.addresses.byId, [action.payload.id]: { ...state.addresses.byId[action.payload.id], city: action.payload.city } } } }; default: return state; }}性能对比MobX 性能优势自动优化：自动追踪依赖，只更新必要的组件批量更新：action 内部的状态变化会被批量处理懒计算：computed 值只在被访问时才计算// MobX 自动优化class Store { @observable items = []; @computed get expensiveValue() { console.log('Computing expensive value'); return this.items.reduce((sum, item) => sum + item.value, 0); }}// 只有在访问 expensiveValue 时才会计算console.log(store.expensiveValue); // 计算一次console.log(store.expensiveValue); // 使用缓存，不计算Redux 性能挑战手动优化：需要使用 reselect、memo 等工具优化全量比较：每次 dispatch 都会比较整个状态树需要手动订阅：需要手动选择需要的数据// Redux 需要手动优化import { createSelector } from 'reselect';const selectItems = (state) => state.items;const selectExpensiveValue = createSelector( [selectItems], (items) => { console.log('Computing expensive value'); return items.reduce((sum, item) => sum + item.value, 0); });// 需要手动选择数据const value = selectExpensiveValue(store.getState());调试对比MobX 调试// 使用 MobX DevToolsimport { makeObservable, observable, action } from 'mobx';class Store { @observable count = 0; constructor() { makeObservable(this); } @action increment() { this.count++; }}// 在浏览器中查看状态变化Redux 调试// 使用 Redux DevToolsimport { createStore } from 'redux';const store = createStore( reducer, window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__());// 可以查看完整的 action 历史、状态变化和时间旅行迁移建议从 MobX 迁移到 Redux重构状态结构：将嵌套状态扁平化创建 action types：定义所有可能的 action编写 reducers：将状态修改逻辑移到 reducers使用中间件：根据需要添加中间件更新组件：使用 useSelector 和 useDispatch从 Redux 迁移到 MobX创建 stores：将 reducer 逻辑转换为 stores使用 observable：将状态转换为 observable添加 actions：将 action creators 转换为 actions更新组件：使用 observer 或 useObserver简化代码：移除不必要的样板代码总结选择 MobX 如果：需要快速开发状态结构复杂且嵌套团队更熟悉面向对象编程希望降低学习成本需要更多的代码灵活性选择 Redux 如果：项目规模较大需要严格的代码规范需要完整的时间旅行调试需要丰富的中间件生态团队偏好函数式编程两者都是优秀的状态管理库，选择哪一个应该基于项目需求和团队情况。在实际项目中，也可以根据不同模块的特点混合使用。

MobX 和 Redux 是两种流行的状态管理库，它们在设计理念和使用方式上有显著差异：架构设计Redux：采用单向数据流架构遵循严格的不可变性原则使用纯函数（reducers）来处理状态更新状态是只读的，只能通过 dispatch action 来修改需要手动选择需要的状态（通过 useSelector）MobX：采用响应式编程架构允许可变状态，但通过 observable 进行追踪可以直接修改状态（在 action 中）自动追踪依赖关系，自动更新相关组件无需手动选择状态，组件自动订阅所需数据代码量和复杂度Redux：需要编写大量的样板代码（actions、action creators、reducers）需要配置 store、middleware、reducers代码结构相对复杂，学习曲线陡峭MobX：代码量少，简洁直观最小化配置，开箱即用学习曲线平缓，容易上手性能Redux：通过 shallowEqual 进行浅比较来决定是否重新渲染需要开发者手动优化性能（如使用 reselect）对于大型应用，可能需要额外的优化策略MobX：细粒度的依赖追踪，只更新真正需要更新的组件自动缓存计算属性，避免不必要的计算性能优化是自动的，开发者无需过多关注TypeScript 支持Redux：需要为 actions、reducers、state 等定义类型类型定义相对复杂，但类型安全性高需要使用类型断言或类型守卫MobX：类型推断更自然，类型定义更简单与 TypeScript 集成更流畅可以充分利用 TypeScript 的类型推断能力调试和可预测性Redux：状态变化完全可预测，易于调试Redux DevTools 提供强大的时间旅行调试功能所有的状态变化都通过 action 记录MobX：调试相对复杂，因为状态可以在多处修改MobX DevTools 提供了调试支持，但不如 Redux 强大需要遵循最佳实践（如使用 action）来提高可预测性适用场景选择 Redux：需要严格的状态管理规范团队规模大，需要明确的代码结构需要时间旅行调试状态变化逻辑复杂，需要中间件支持选择 MobX：追求开发效率和代码简洁性项目规模中小型需要快速原型开发团队对函数式响应式编程更熟悉总结Redux 更适合需要严格架构和可预测性的大型项目，而 MobX 更适合追求开发效率和简洁性的项目。选择哪种库应该根据项目需求、团队经验和长期维护考虑来决定。

在Redux中，中间件是一种强大的机制，允许开发者在action被发送到reducer之前插入自己的逻辑。创建自定义的Redux中间件涉及到编写一个函数，该函数按照Redux中间件API的规格返回一个满足特定签名的函数。我将向您展示如何自定义实现一个简单的日志中间件，该中间件的作用是在action被派发时在控制台输出日志信息。以下是自定义Redux中间件的基本步骤：编写一个函数，该函数接收store的dispatch和getState方法。该函数返回一个接收下一个中间件的next函数的函数。返回的函数再返回一个接收action的函数。在最内层的函数体内，可以执行自定义的逻辑，然后调用next(action)将action传递给链中的下一个中间件或reducer。下面是一个自定义日志中间件的例子：// 自定义日志中间件const loggerMiddleware = store => next => action => { // 自定义的逻辑：在当前action被处理之前输出日志 console.log('dispatching', action); // 调用链中的下一个中间件或reducer let result = next(action); // 自定义的逻辑：在action被处理后输出新的状态 console.log('next state', store.getState()); // 返回result，因为middleware的链需要从next(action)获取返回值 return result;};export default loggerMiddleware;在上述的中间件代码中：store: Redux store实例，它包含了dispatch和getState方法。next: 是一个将action传递给链中下一个处理者（中间件或reducer）的函数。action: 是当前正在处理的action对象。使用这个中间件的典型方式是在创建Redux store时应用它：import { createStore, applyMiddleware } from 'redux';import rootReducer from './reducers';import loggerMiddleware from './middleware/loggerMiddleware';// 使用applyMiddleware来增强store，添加自定义的loggerMiddlewareconst store = createStore( rootReducer, applyMiddleware(loggerMiddleware));export default store;在这个例子中，任何派发到store的action都会先经过loggerMiddleware这个中间件，在控制台输出action信息，然后继续沿中间件链传递，直到最终被reducer处理。这只是自定义中间件的一个简单例子，但您可以根据需要在中间件中实现更复杂的逻辑，例如异步操作、路由导航或其他您想要的任何自定义行为。