彻底搞懂Result类型在实际项目中的应用与避坑指南

UI素伟发布于 2026-03-21 03:14:48 组件阅读 1,106

原创

本文链接：https://www.jztheme.com/blog/component/37731.html

UI素伟

赞 25 收藏反馈

项目初期的技术选型

最近在做一个后台类的管理平台，核心功能是处理一批数据导入、校验和结果反馈。用户上传一个Excel，系统解析后返回成功多少条、失败多少条，并列出具体错误原因。一开始没想太多，直接用个简单的对象来传递结果：

const result = {
  success: true,
  data: [...],
  errors: []
};

挺常见的写法对吧？我也用了好几年了。但这次项目里，这种结构开始扛不住了——校验逻辑越来越复杂，有些步骤还要分阶段执行，中间还要记录日志、状态码、重试次数……返回结构乱得不行，同事接手时总问我：这个 error 到底是前端报的还是后端返回的？success 字段到底代表什么？网络请求成功也算 success 吗？

后来我决定换个思路，引入 Result 这种模式。不是自己造轮子，而是参考 Rust 的 Result 枚举（Ok / Err）和 fp-ts 里的类型设计，但不用那么函数式，咱就搞个轻量版，在 JS 里也能跑得起来。

我怎么用的 Result

最终我抽象出两个构造函数：ok 和 err，返回带 type 标识的对象：

function ok(data, message = '操作成功') {
  return { type: 'ok', data, message };
}

function err(errorCode, message, details = null) {
  return { type: 'err', errorCode, message, details };
}

然后所有异步操作都统一返回这种结构，比如文件解析：

async function parseExcel(file) {
  if (!file) {
    return err('FILE_REQUIRED', '请上传文件');
  }

  try {
    const data = await readXlsxFile(file);
    if (data.length === 0) {
      return err('FILE_EMPTY', '文件为空，请检查内容');
    }
    return ok(data, '文件解析成功');
  } catch (e) {
    return err('PARSE_ERROR', '文件解析失败，请确认格式正确', e.message);
  }
}

上层调用的时候就很简单了：

const result = await parseExcel(file);

if (result.type === 'ok') {
  console.log('数据条数:', result.data.length);
} else {
  showError(result.message);
  // 根据 errorCode 做不同处理
  if (result.errorCode === 'FILE_EMPTY') {
    // 引导用户重新上传
  }
}

看着简单，但这套结构把“结果”和“错误”彻底分离了，不会出现 success: true 却又有 error 字段的尴尬情况。

最大的坑：嵌套层级太多

刚开始我觉得这方案挺优雅，直到我们加了多阶段校验流程。比如先解析文件 → 再校验每行数据 → 然后去重 → 最后提交到服务器。每个阶段都可能出错，于是代码变成这样：

const parseResult = await parseExcel(file);
if (parseResult.type === 'err') {
  return parseResult;
}

const validateResult = validateRows(parseResult.data);
if (validateResult.type === 'err') {
  return validateResult;
}

const dedupeResult = deduplicate(validateResult.data);
if (dedupeResult.type === 'err') {
  return dedupeResult;
}

const apiResult = await submitToServer(dedupeResult.data);
if (apiResult.type === 'err') {
  return apiResult;
}

return ok(apiResult.data, '全部完成');

一连串 if 判断，像面条代码。我写了三遍几乎一样的模板，自己都看不下去。更糟的是，TypeScript 类型推导在这种手动判断下也变弱了，IDE 经常提示 “property data does not exist on type err”。

折腾了半天发现，其实可以封装一个 run 函数来做“管道式”处理：

function run(...fns) {
  return async (initialValue) => {
    let current = initialValue;

    for (const fn of fns) {
      let result;
      if (current.type === 'ok') {
        try {
          result = await fn(current.data);
        } catch (e) {
          result = err('UNKNOWN_ERROR', '未知异常', e);
        }
      } else {
        result = current; // 错误直接透传
      }

      if (result.type === 'err') {
        return result;
      }
      current = result;
    }

    return current;
  };
}

然后链式调用就清爽多了：

const processor = run(
  parseExcel,
  validateRows,
  deduplicate,
  submitToServer
);

const finalResult = await processor(file);

这里注意我踩过好几次坑：run 函数必须能处理同步和异步函数，所以用了 await 包一层；另外初始值如果是 Promise，也要兼容。最后改完，整段流程从 20 行缩到 4 行，可读性提升明显。

和 API 返回格式的对齐问题

另一个头疼点是后端接口返回的数据结构和前端的 Result 不一致。他们用的是传统 { code: 0, data: {}, msg: ” } 模式。我在封装 fetch 的时候做了统一转换：

async function request(url, options) {
  try {
    const res = await fetch(url, options);
    const json = await res.json();

    if (json.code === 0) {
      return ok(json.data, json.msg);
    } else {
      return err(API_${json.code}, json.msg || '请求失败');
    }
  } catch (e) {
    return err('NETWORK_ERROR', '网络异常，请检查连接');
  }
}

现在所有接口调用都走 request，自动转成统一结构。唯一遗憾的是，后端有些错误码太笼统，比如 code=500 可能是参数错也可能是服务挂了，没法精细化处理。这个问题到现在也没完全解决，只能靠 message 字段关键词匹配临时 workaround，比如判断是否包含“超时”或“数据库”字眼。