React面试题手册

Zustand 性能优化先看订阅粒度：组件只订阅自己需要的字段，不要 useStore() 拿整个 store。多个字段一起取时用 shallow 或拆成多个 selector；状态太大时按领域拆 store；异步更新用函数式 set 或 get() 避免旧值。真正的瓶颈通常不是 Zustand，而是选择器返回新对象、组件订阅过宽、列表渲染太重。追问为什么 useStore() 容易造成重渲染？它订阅整个 store，任何字段变化都会让组件重新渲染。字段越多，误伤越明显。shallow 能解决什么问题？selector 返回对象或数组时，每次都是新引用。shallow 会比较第一层字段，字段没变就不触发更新。拆 store 一定更好吗？不一定。强相关状态放一起更好维护；变化频率差异很大、业务边界清楚时再拆，否则会增加同步成本。批量更新要手动处理吗？React 18 下大多数场景会自动批处理。更重要的是把相关字段放在一次 set 里，避免中间状态被订阅者看到。写段代码import { shallow } from 'zustand/shallow';const count = useStore((s) => s.count);const inc = useStore((s) => s.inc);const userView = useStore( (s) => ({ name: s.user.name, role: s.user.role }), shallow);const useStore = create((set) => ({ count: 0, inc: () => set((s) => ({ count: s.count + 1 }))}));

Zustand 处理异步不需要额外机制，直接在 action 里写 async/await，用 set 更新 loading/data/error，需要最新状态时用 get()。如果是服务端缓存、重试、失效刷新这类问题，优先交给 React Query 或 SWR，Zustand 只保存跨页面共享的 UI 或业务状态。追问async action 里为什么要用 get()？异步代码执行时，闭包里的旧值可能已经过期。get() 读取的是当前 store 状态，适合在 await 后继续基于最新状态更新。loading 和 error 应该怎么设计？简单请求可以放 loading: boolean；多个并发请求最好按 key 存状态，避免 A 请求结束把 B 请求的 loading 误关掉。Promise 链和 async/await 有区别吗？能力上差不多。面试回答用 async/await 更清楚，但要说明 action 可以返回 Promise，组件或测试里可以继续 await。什么时候不该把请求全塞进 Zustand？需要缓存、分页、去重、后台刷新、请求取消时，不要自己造一套数据请求框架，直接用 React Query/SWR 更稳。写段代码const useStore = create((set, get) => ({ user: null, loading: false, error: null, fetchUser: async (id) => { set({ loading: true, error: null }); try { const user = await fetch(`/api/users/${id}`).then(r => r.json()); set({ user, loading: false }); } catch (e) { set({ error: e.message, loading: false }); } }}));

Zustand store 单测重点是把状态恢复到干净初始值，再验证 action、异步状态和 selector 行为。同步 action 可以直接用 getState() 调；React hook 场景用 renderHook 和 act；异步 action 要 mock 请求并等待 Promise 结束。面试里别只说“很好测”，要提到全局 store 会污染用例，必须在 beforeEach 重置。追问为什么每个测试前要重置 store？Zustand store 默认是模块级单例，上一个测试改过的状态会留到下一个测试，导致用例顺序一变就失败。测 action 一定要 renderHook 吗？不一定。纯 store 逻辑用 useStore.getState().action() 更快；只有要验证 hook 订阅和组件重渲染时，才需要 renderHook。异步 action 怎么测？mock fetch 或请求层，调用 action 后断言 loading、data、error 的最终状态。需要中间态时，可以分阶段 await。selector 性能怎么测？订阅一个具体 selector，更新无关字段，断言渲染次数不变；再更新目标字段，断言它才重新触发。写段代码beforeEach(() => { useStore.setState({ count: 0, user: null }, true);});test('increments count', () => { useStore.getState().increment(); expect(useStore.getState().count).toBe(1);});test('fetch user', async () => { vi.spyOn(global, 'fetch').mockResolvedValue({ json: async () => ({ id: 1 }) }); await useStore.getState().fetchUser(1); expect(useStore.getState().user).toEqual({ id: 1 });});

Zustand 自定义中间件本质是包一层 config：拦截 set/get/api，再把增强后的能力交还给 store。常见用途是日志、校验、性能埋点、撤销重做。面试里先说函数签名，再强调两点：不要破坏原始 set 语义；组合多个 middleware 时外层先执行，顺序会影响结果。追问自定义 middleware 和普通 action 封装有什么区别？普通 action 只管某个业务动作；middleware 能统一拦截所有状态更新，适合横切能力，比如日志、持久化、校验。set 包装时最容易踩什么坑？别忘了转发 replace 参数，也不要在 middleware 里无条件再次调用增强后的 set，否则可能递归或改变 replace 行为。多个 middleware 的执行顺序怎么看？create(a(b(config))) 中，a 先拿到 config 并包装，实际更新时通常外层逻辑先触发。日志、persist、immer 混用时要明确谁先处理原始对象。实际项目会怎么用？我更倾向把日志、权限校验、状态快照放 middleware，业务状态变化仍留在 action 里，避免 middleware 变成黑盒业务层。写段代码const logger = (config) => (set, get, api) => config((partial, replace) => { const prev = get(); const ret = set(partial, replace); console.log('zustand change', { prev, next: get() }); return ret; }, get, api);const useStore = create(logger((set) => ({ count: 0, inc: () => set((s) => ({ count: s.count + 1 }))})));

useQuery 用来读数据，useMutation 用来改数据。读数据通常自动执行、会按 queryKey 缓存，并处理 loading、error、重试和后台刷新；改数据不会因为组件渲染就自动执行，需要调用 mutate，成功后通常 invalidateQueries 让相关列表重新获取，或者做乐观更新。追问为什么 useMutation 不像 useQuery 那样自动缓存？因为写操作的重点不是展示“这次提交的返回值”，而是让服务器状态发生变化。变化后要么让相关 query 失效重新拉取，要么手动更新缓存。提交表单应该用哪个？用 useMutation。表单提交是创建或更新资源，应该由用户动作触发，而不是组件一挂载就执行。删除一条数据后列表怎么刷新？常见做法是在 onSuccess 里调用 queryClient.invalidateQueries，让列表 query 重新获取。体验要求高时可以先做乐观删除，失败再回滚。queryKey 在 useQuery 里为什么重要？它决定缓存身份。列表、详情、筛选条件都应该进 queryKey，否则容易拿到旧数据或串数据。写段代码const todos = useQuery({ queryKey: ['todos'], queryFn: fetchTodos });const addTodo = useMutation({ mutationFn: createTodo, onSuccess: () => { queryClient.invalidateQueries({ queryKey: ['todos'] }); },});addTodo.mutate({ title: 'learn query' });

React Query 管服务器状态，Redux 管客户端状态。服务器状态来自后端，会过期、要缓存、要重试、要和接口同步；客户端状态只存在前端，比如弹窗开关、主题、复杂表单流程。项目里常见做法不是二选一，而是用 React Query 处理接口数据，用 Redux、Zustand 或 Context 处理真正的全局 UI 状态。追问React Query 能替代 Redux 吗？只能替代一大部分“把接口数据塞进 Redux”的写法。购物车草稿、权限后的菜单展开状态、跨页面编辑流程这类客户端状态，React Query 不负责。为什么接口数据不适合直接放 Redux？你要自己写 loading、error、缓存过期、重复请求合并、重试和失效逻辑。React Query 把这些变成默认能力，代码量少很多。什么时候还应该用 Redux？当状态更新规则复杂、多个模块共享同一份前端状态、需要严格可追踪的状态变更时，Redux 仍然合适。已经重度使用 Redux Toolkit 的项目，也可以考虑 RTK Query。两者一起用会不会混乱？不会，边界划清就行：接口返回的数据归 React Query，用户在页面上的交互状态归客户端状态库。最怕的是同一份数据两边各存一份。写段代码const { data: user } = useQuery({ queryKey: ['user', id], queryFn: () => fetchUser(id),});const theme = useSelector(state => state.ui.theme);

React Query 的高级特性主要解决三个问题：按条件发请求、同时发多个请求、让缓存数据在合适时机变新。依赖查询用 enabled 控制执行时机；并行查询用多个 useQuery 或 useQueries；窗口聚焦重新获取用 refetchOnWindowFocus 保证页面回来时数据不过期。回答时要补一句：这些能力都围绕服务器状态，不是替代本地 UI 状态。追问依赖查询为什么不用 if 包住 useQuery？Hook 不能放进条件语句里，否则调用顺序会变。正确做法是始终调用 useQuery，用 enabled: !!id 控制是否真正请求。多个 useQuery 和 useQueries 怎么选？数量固定时直接写多个 useQuery，可读性更好。数量来自数组时用 useQueries，例如按一批 id 拉详情。refetchOnWindowFocus 会不会导致请求太多？会，所以后台管理页、实时看板适合开启；编辑表单、低频静态数据可以关闭，或配合 staleTime 降低重复请求。无限滚动靠什么实现？用 useInfiniteQuery，关键是 getNextPageParam 返回下一页参数，返回 undefined 表示没有更多。写段代码const user = useQuery({ queryKey: ['user', id], queryFn: getUser });const posts = useQuery({ queryKey: ['posts', user.data?.id], queryFn: () => getPosts(user.data.id), enabled: !!user.data?.id, staleTime: 60_000, refetchOnWindowFocus: true,});const results = useQueries({ queries: ids.map(id => ({ queryKey: ['todo', id], queryFn: () => getTodo(id) }))});

React Query 的错误处理要分两层：组件里展示用户能看懂的错误，全局里做日志和兜底通知。重试不要一刀切，网络抖动和 5xx 可以重试，401、403、404、表单校验这类 4xx 通常不该重试；否则只是把错误请求重复打到服务端。追问retry 默认是几次？浏览器端查询默认会重试 3 次，并使用退避延迟；服务端渲染场景通常不建议重试太多，否则会拖慢响应。retry 和 refetch 有什么区别？retry 是一次请求失败后的自动补救，refetch 是用户或程序主动重新拉取。错误页里的“再试一次”通常调用 refetch 或 reset error boundary。Mutation 失败要怎么处理？如果做了乐观更新，onMutate 里先保存旧数据，onError 里回滚，再提示用户。不要只弹 toast，却让缓存停在错误状态。全局 onError 适合做什么？适合上报 Sentry、统一 toast、处理登录过期。具体页面文案仍应在业务组件里判断。写段代码useQuery({ queryKey: ['todos'], queryFn: getTodos, retry: (count, error: any) => { if ([400, 401, 403, 404].includes(error.status)) return false; return count < 3; }, retryDelay: i => Math.min(1000 * 2 ** i, 30_000),});

React Query 接入 Suspense 后，加载状态交给 Suspense fallback，错误交给 Error Boundary。实际项目里优先用 useSuspenseQuery，而不是在每个组件里判断 isLoading。注意：开启 Suspense 不代表不用管错误，网络失败会抛给最近的错误边界；如果要让“重试”按钮生效，还要配 QueryErrorResetBoundary。追问useSuspenseQuery 和 useQuery 有什么区别？useSuspenseQuery 成功返回时 data 一定有值，加载中会挂起组件。你少写了 loading 分支，但必须准备好 Suspense 和错误边界。Error Boundary 应该放在哪里？放在页面块级别通常最合适。太外层会导致整页白掉，太内层又会让错误处理重复。有缓存时还会进入 fallback 吗？已有可用缓存时通常直接渲染；queryKey 改变触发新请求时，可能再次 fallback。交互更新可用 startTransition 降低界面闪烁。SSR 里能直接用吗？要谨慎。Next.js 等场景通常配合预取、dehydrate/hydrate，或使用框架推荐的 Suspense 数据方案。写段代码<QueryErrorResetBoundary> {({ reset }) => ( <ErrorBoundary onReset={reset} fallbackRender={({ resetErrorBoundary }) => ( <button onClick={resetErrorBoundary}>重试</button> )}> <Suspense fallback={<Spinner />}> <UserPanel /> </Suspense> </ErrorBoundary> )}</QueryErrorResetBoundary>

项目里不要把 useQuery 散落在组件里。更稳的做法是按业务域组织：API 函数只负责请求，自定义 Hook 负责暴露查询，query key 工厂负责命名和失效。query key 用数组，从宽到窄写，比如 ['users', 'detail', id]；凡是 queryFn 依赖的参数都必须进 key，否则缓存可能串数据。追问为什么不建议直接写字符串 key？字符串很难表达层级，也不方便批量失效。数组 key 可以让你失效整个用户域、某个详情页，或某个筛选列表。API 函数和 Hook 为什么要分开？API 函数可独立测试，也能被预取、SSR、mutation 复用。Hook 里再放 staleTime、enabled、select 等 React Query 配置。项目结构按 api、hooks 分，还是按 feature 分？小项目都可以；中大型项目更推荐 feature 分组，例如 features/user/api.ts、queries.ts、keys.ts，修改用户模块时不用跨目录找文件。命名上最容易踩什么坑？列表和详情共用一个 key、筛选条件没放进 key、mutation 成功后失效范围太大。这些都会造成脏数据或无意义重请求。写段代码export const userKeys = { all: ['users'] as const, detail: (id: string) => [...userKeys.all, 'detail', id] as const,};export function useUser(id: string) { return useQuery({ queryKey: userKeys.detail(id), queryFn: () => getUser(id), staleTime: 60_000, });}