React Native中RTK Query的两种Mutation写法哪种更优？是否有隐患？

结论 #

优先推荐使用第二种基于.unwrap()的写法，它更贴合RTK Query的设计初衷，代码逻辑更清晰，也能避免第一种写法的潜在问题。

两种写法的核心差异 #

RTK Query 的 useMutation 返回的调用函数，执行后会返回一个永远不会 reject 的 Promise——它只会 resolve 成一个包含 data/error/status 等字段的结果对象。

• 第一种写法：通过 await 获取该结果对象，手动判断 data 或 error 字段分支处理逻辑
• 第二种写法：调用 .unwrap() 方法，将这个特殊 Promise 转换为标准 Promise 行为——成功时 resolve 出 data，失败时直接 reject 出 error，适配常见的 .then()/.catch() 或 async/await 流程

第一种写法的潜在问题 #

虽然当前运行正常，但长期维护存在以下隐患：

• 冗余且易错的判断逻辑：每次都要手动检查 data/error 字段，容易出现漏判（比如忽略 pending 状态、写错字段名）
• 违背Promise直觉：团队新人容易误解这个Promise的行为，比如下意识用 try/catch 包裹 await，但实际上不会触发 catch，导致逻辑混乱
• 扩展性差：后续如果需要联动loading状态、处理更多异常场景，手动判断的写法会快速变得臃肿

规范建议 #

如果团队更习惯 async/await 语法，可以把第二种写法改成更易读的形式，兼顾 .unwrap() 的优势：

const [someFunctionality] = useSomeFunctionalityMutation();

const handleFunctionality = async (someParams) => {
  try {
    await someFunctionality(someParams).unwrap();
    dispatch(successAction);
  } catch (error) {
    dispatch(errorAction);
    setSomeState(error);
  }
};

同时建议团队统一规范：

• 所有Mutation副作用处理都通过 .unwrap() 转换为标准Promise
• 优先使用 async/await + try/catch 的组合（比链式调用更易读）
• 避免手动判断RTK Query返回的结果对象字段，减少人为错误

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