React函数组件中使用try-catch块是否为反模式？

这种在组件顶层用try-catch包裹渲染逻辑的做法属于反模式，具体影响和原因如下：

• 破坏React错误边界机制：React设计了错误边界（Error Boundary）组件来统一捕获子树的渲染错误，实现优雅降级。如果直接在组件内部用try-catch拦截错误，会跳过错误边界的处理流程，既不符合React的错误处理规范，也会导致全局错误监控失效。
• 混淆异常与分支逻辑：异常机制的初衷是处理意外的运行时错误，而foo、bar这类属于预期的UI分支条件。用throw/catch来控制UI渲染流程，会让代码逻辑变得晦涩，其他开发者很难快速理清渲染条件，后续维护成本极高。
• 不必要的性能损耗：异常抛出和捕获的执行开销远大于普通的条件判断，组件每次渲染都会触发try块的执行，频繁渲染场景下会额外增加性能负担。

正确的做法：用条件判断处理UI分支 #

把预期的UI分支逻辑用if-else直接处理，代码清晰易懂，也符合React的设计思路：

function SomeScreen() {
  let error = null;
  if (foo) {
    error = new Error("触发foo条件错误");
  } else if (bar) {
    error = new Error("触发bar条件错误");
  }

  if (error) {
    return <ErrorComponent error={error} />;
  }
  return <Children />;
}

什么时候适合用try-catch？ #

在组件内部处理非渲染阶段的意外错误时可以用，比如：

• useEffect中处理异步请求的错误
• 事件处理函数中捕获操作异常
• 自定义Hook内部处理逻辑错误

这些场景下的错误属于意外情况，用try-catch能避免组件崩溃，同时不会干扰正常的UI分支逻辑。

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