疑难杂症：React 打印功能卡死问题分析

1. 问题背景

最近在开发采购单打印功能时遇到了一个非常奇怪的问题：浏览器在特定条件下会完全卡死。这个问题的诡异之处在于它的触发条件较为苛刻，必须同时满足四个条件才会出现。

经过深入分析，发现这个问题与 React 开发模式的错误处理机制和 Chrome 浏览器的打印事件处理存在兼容性冲突有关，React 官方在 v17 版本中已经修复了这个问题。

环境说明：本问题在 React 16.x + Chrome 浏览器 + 开发模式下复现，React v17+ 或生产环境或 firefox 无此问题。

2. 问题现象

会导致卡死的代码

// ❌ 会导致浏览器卡死的代码
useEffect(() => {
  if (isPrinting) {
    setTimeout(() => {
      // 条件1: Print.print 在 setTimeout 中调用
      Print.print({
        pageId,
        onAfterPrint: () => {
          setIsPrinting(false) // 条件2: afterprint 中直接 setState
        },
      })
    }, 0)
  }
}, [isPrinting])
// 条件3: React 运行在 development 模式
// 条件4: React 版本 < v17

不会卡死的代码

// ✅ 直接调用 Print.print（去掉 setTimeout）
useEffect(() => {
  if (isPrinting) {
    Print.print({
      pageId,
      onAfterPrint: () => {
        setIsPrinting(false) // 不会卡死
      },
    })
  }
}, [isPrinting])

// ✅ 在 afterprint 中使用异步更新
useEffect(() => {
  if (isPrinting) {
    setTimeout(() => {
      Print.print({
        pageId,
        onAfterPrint: () => {
          setTimeout(() => {
            // 关键修复
            setIsPrinting(false)
          }, 0)
        },
      })
    }, 0)
  }
}, [isPrinting])

3. 触发条件分析

通过一系列控制变量测试，我发现这个问题需要同时满足四个条件：

Print.print 在 setTimeout 中调用 - 改变了执行上下文
在 afterprint 事件回调中直接调用 setState - 触发 React 更新机制
React 运行在 development 模式 - 使用特殊的错误处理机制
React 版本小于 v17 - v17 为 Chrome 的 bug 进行了兜底处理

去掉任何一个条件都不会出现卡死现象。

4. 技术原理分析

React 开发模式的错误处理机制

React 在开发模式下使用 invokeGuardedCallbackDev 进行错误处理，这个机制通过创建假的 DOM 事件来捕获错误，以提供更好的调试体验。以下是简化版的实现：

// 生产模式 - 简单直接
function invokeGuardedCallbackProd(name, func, context, ...args) {
  try {
    return func.apply(context, args)
  } catch (error) {
    onError(error)
  }
}

// 开发模式 - 使用"假 DOM 事件"技巧
function invokeGuardedCallbackDev(name, func, context, ...args) {
  let didError = false
  let error = null

  // 创建假的 DOM 元素和事件
  const fakeNode = document.createElement('react')
  const fakeEvent = document.createEvent('Event')

  const handleError = (e) => {
    didError = true
    error = e.error
  }

  window.addEventListener('error', handleError)

  try {
    fakeNode.addEventListener('fake-react-event', () => {
      func.apply(context, args)
    })

    // ⚠️ 关键冲突点：触发假 DOM 事件
    fakeNode.dispatchEvent(fakeEvent)
  } finally {
    window.removeEventListener('error', handleError)
  }

  if (didError) {
    this.onError(error)
  }
}

为什么使用假 DOM 事件？

开发模式不直接使用 try-catch 的原因是为了绕过 Chrome DevTools 的 Pause on caught exceptions 设置，提供更好的调试体验。

官方确认的问题

这个问题已被 React 官方确认并修复：

React Issue #16734：用户报告在 Chrome 中调用 window.print() 时出现的问题
React PR #19220：Dan 的修复，为 Dev 模式下的 invokeGuardedCallbackDev 增加了兜底，即如果 dispatchEvent 失败，则调用 invokeGuardedCallbackProd（生产模式进行处理）

无限循环的形成机制

基于错误堆栈和官方 Issue，可以确定无限循环的触发者是 React 的错误处理机制：

setTimeout 中的 Print.print 改变了执行上下文
afterprint 事件在异步上下文中触发 setState
React 的 commitRootImpl 调用 invokeGuardedCallbackDev
由于执行上下文混乱，dispatchEvent 调用失败（Chrome 的 bug 导致）
React 错误恢复机制重试执行
形成递归调用链：scheduleUpdateOnFiber → commitRootImpl → invokeGuardedCallbackDev → dispatchEvent → ...（进行错误恢复） → scheduleUpdateOnFiber

`setTimeout` 的关键作用

setTimeout 改变了执行上下文，使得打印操作在异步环境中执行，这是触发问题的关键条件之一。去掉 setTimeout 后，afterprint 在同步执行流中处理，不会触发 Chrome 的 bug 导致 dispatchEvent 失败。

5. 解决方案

基于对根本原因的理解，解决方案就很清晰了：

// ✅ 解决方案 1
setTimeout(() => {
  Print.print({
    pageId,
    onAfterPrint: () => {
      // 关键：将 setState 推迟到下一个事件循环
      setTimeout(() => {
        setIsPrinting(false)
      }, 0)
    },
  })
}, 0)


// ✅ 解决方案 2
Print.print({ // 保证同步调用打印
  pageId,
  onAfterPrint: () => {
    setIsPrinting(false)
  },
})

解决原理：

将 setState 推迟到下一个事件循环
脱离 Chrome 的 afterprint 事件上下文
避免在 afterprint 回调中直接触发 React 的错误处理机制
打破 React 重试与 Chrome 异常标记的无限循环

6. 总结

这个打印功能卡死问题，让我意识到解决问题时两方面的很重要：

系统性的分析能力 - 控制变量、逐步缩小问题范围
技术深度 - 问题本身不是由业务代码导致的，需要不断向底层深入并分析，如前端框架、浏览器原理、异步编程

虽然最终的解决方案只是一行setTimeout，但排查问题的过程很重要，真正理解了背后的原理会让我们知道自己在做什么。