如何在Redux中“清洗”API响应？求规范处理实践

这确实是前后端协作初期非常头疼的问题——接口结构变动、字段类型不符或者意外null值，分分钟让你的应用崩溃。你用defaultsDeep的思路方向是对的，但它确实只处理undefined的情况，针对你遇到的场景，我分享几个实用的解决方案：

1. 自定义数据清洗函数（最灵活的方案） #

针对你的user结构写一个专门的清洗函数，对每个字段做严格的类型校验和转换，确保输出完全匹配InitialState.user的结构。这种方式可以精准处理各种异常情况：

const sanitizeUser = (rawUser) => {
  // 处理address：如果是null/undefined，直接用默认结构；否则保留有效字段
  const sanitizedAddress = rawUser.address 
    ? {
        city: typeof rawUser.address.city === 'string' ? rawUser.address.city : '',
        country: typeof rawUser.address.country === 'string' ? rawUser.address.country : ''
      }
    : { city: '', country: '' };

  // 处理hobbies：如果是数组直接用；如果是带list的对象就取list；否则用空数组
  const sanitizedHobbies = Array.isArray(rawUser.hobbies)
    ? rawUser.hobbies
    : (rawUser.hobbies?.list ?? []);

  // 最终合并所有字段，确保每个字段类型都符合预期
  return {
    id: typeof rawUser.id === 'number' ? rawUser.id : -1,
    name: typeof rawUser.name === 'string' ? rawUser.name : '',
    hobbies: sanitizedHobbies,
    address: sanitizedAddress
  };
};

// 在reducer中使用
case FETCH_USER_SUCCESS: {
  return {
    ...state,
    user: sanitizeUser(payload.data),
  }
}

这种方案的好处是完全可控，你可以根据后端可能出现的各种异常情况（比如hobbies变成对象、address返回null）针对性处理，确保进入Redux Store的数据100%符合预期结构。

2. 使用Schema验证库（更优雅的长期方案） #

如果你的应用有大量类似场景，推荐用Schema验证库（比如Zod、Yup）来定义数据结构规则，自动完成校验和转换。以Zod为例：

import { z } from 'zod';

// 先定义地址的Schema，处理null的情况
const AddressSchema = z.object({
  city: z.string().default(''),
  country: z.string().default('')
}).nullable().transform(val => val ?? { city: '', country: '' });

// 定义用户的Schema，处理hobbies的两种可能结构
const UserSchema = z.object({
  id: z.number().default(-1),
  name: z.string().default(''),
  hobbies: z.union([
    z.array(z.string()),
    z.object({ list: z.array(z.string()) })
  ]).transform(val => Array.isArray(val) ? val : val.list ?? []),
  address: AddressSchema
}).default(InitialState.user);

// 在reducer中使用
case FETCH_USER_SUCCESS: {
  // parse会自动校验并转换数据，不符合规则的会抛出错误（可以用safeParse处理异常）
  const sanitizedUser = UserSchema.parse(payload.data);
  return {
    ...state,
    user: sanitizedUser,
  }
}

这种方案的优势是代码更简洁，Schema定义可以复用，还能自动生成TypeScript类型（如果用TS的话），同时提供了错误处理机制，方便你排查后端返回的异常数据。

3. 组件层面的兜底防护（最后一道防线） #

即使在Store层面做了清洗，也可以在组件中使用JS的可选链操作符（?.）和空值合并运算符（??）做兜底，避免意外崩溃：

// 渲染hobbies时
{user.hobbies?.map((hobby) => (
  <div key={hobby}>{hobby}</div>
)) ?? []}

// 渲染address.city时
<p>城市：{user.address?.city ?? '未填写'}</p>

这层防护可以作为最后一道保险，尤其是在你来不及修改Store处理逻辑的时候。

总结 #

推荐的流程是：用Schema验证库（或自定义清洗函数）在数据进入Redux Store前完成校验和转换，确保Store中的数据结构完全符合预期；同时在组件层面用可选链做兜底，双管齐下避免崩溃。这样既保证了数据的一致性，又能应对后端接口的各种变动。

内容的提问来源于stack exchange，提问作者Tomasz Mularczyk