React组件try块中校验API返回data是否必要？属最佳实践吗？

先看你的代码：

const getPhotos = async (page?: number) => { 
  setLoading(true);
  try {
    const data = await endpoints.getCuratedPhotos(page)
    if (!data) {
      setError('No Photos found')
      setLoading(false);
    } else {
      setPhotos(data);
      setSearchQuery(null)
      setLoading(false);
    }

  } catch (e) {
    console.log('error something went wrong', e);
    setError(`error something went wrong, ${e}`)
    setLoading(false);
  }
}

useEffect(() => {
  getPhotos();
}, [])

1. try块中检查!data是否必要？属于最佳实践吗？ #

这完全取决于后端接口的返回约定：

• 如果后端明确约定：成功请求（HTTP 20x）时，无匹配数据就返回null/undefined，那这个检查是必要的——因为这种情况属于业务层面的“无数据”，不属于请求错误，catch块根本捕获不到。
• 如果后端约定：成功请求时始终返回数组（哪怕是空数组[]），那这个检查就没必要，甚至可能引发误判（比如后端返回空数组时，!data会判定为true，错误触发“无照片”提示）。

最佳实践是：先和后端对齐接口返回规范，优先让后端返回空数组而非null来表示无数据，这样前端可以统一用data.length === 0来判断，逻辑更清晰；如果后端确实会返回null，那这个检查就是合理的，属于业务异常处理的一部分。

2. 除了修改端点URL，还有哪些场景会触发!data判断？ #

常见场景包括：

• 后端逻辑变更：比如原本能返回数据的接口，因业务调整，在查询不到资源时返回null
• 响应被中间件修改：前端请求拦截器/后端网关等中间件，把原本的响应体修改为null
• 空响应体：接口返回HTTP 204（No Content）状态码，此时大部分HTTP库（如axios）会把data解析为null
• 分页越界：请求的页码超过总页数，后端返回null表示无更多数据
• 权限限制：用户无权限访问资源，但后端未返回403错误，而是返回null（这种属于后端不规范，但前端需要兼容）

3. 仅依靠catch块捕获所有错误是否足够？ #

完全不够。catch块只能捕获请求层面的异常，比如：

• 网络错误（断网、DNS解析失败）
• HTTP状态码4xx/5xx的错误（部分HTTP库需要配置才会把4xx/5xx抛出为异常，比如axios默认不抛出404）
• 请求被中断、超时等

但业务层面的异常（比如成功请求但返回null/无效数据）不会触发catch，必须在try块内做业务校验。此外，如果你的HTTP库默认不把4xx/5xx视为异常，这些错误也不会进入catch，还需要额外检查响应状态码。

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