JavaScript Promise错误处理：避免未捕获reject的隐患

1. 为什么Promise未捕获的reject会成为"沉默的杀手"

在JavaScript异步编程中，Promise未捕获的reject错误就像一颗定时炸弹。我曾在生产环境遇到过这样的场景：一个电商促销页面的优惠券领取功能突然失效，控制台没有任何报错，但用户点击后毫无反应。经过两小时的排查，最终发现是一个Promise的reject没有被捕获，导致后续逻辑中断。

这种错误最危险之处在于它不会像同步错误那样直接抛出到控制台。当Promise被reject且没有对应的.catch()处理时，浏览器控制台只会显示一行灰色的警告："Uncaught (in promise) Error..."。在复杂的异步调用链中，这种错误很容易被忽视。

现代浏览器和Node.js环境对未捕获的Promise rejection有不同的处理方式：

• Chrome v49+：控制台警告
• Node.js v15+：会触发'unhandledRejection'事件并终止进程
• 旧版Node.js：仅警告不终止

2. 四种必须掌握的reject捕获方案

2.1 基础链式捕获：.catch()的正确姿势

最基本的错误处理方式是在Promise链末尾添加.catch()：

javascript复制fetch('/api/data')
  .then(response => response.json())
  .then(data => {
    if(!data.valid) throw new Error('Invalid data')
    return processData(data)
  })
  .catch(error => {
    console.error('Fetch failed:', error)
    showUserError('加载失败，请重试')
  })

常见误区：

1. 每个.then()后都加.catch() → 导致错误处理冗余
2. 在async函数中忘记返回Promise → 导致错误处理链断裂
3. 在catch中不重新抛出错误 → 上层无法感知错误

最佳实践是保持单一错误处理点，通常在调用链的最外层设置一个.catch()。

2.2 async/await中的try-catch陷阱

虽然async/await让异步代码看起来像同步的，但错误处理需要特别注意：

javascript复制async function loadUserProfile() {
  try {
    const user = await fetchUser()  // 可能reject
    const posts = await fetchPosts(user.id) // 依赖前一个await
    return { user, posts }
  } catch (error) {
    // 会捕获链上所有await的reject
    sentry.captureException(error)
    return null
  }
}

容易踩的坑：

• 在循环中使用await时，try-catch的位置不当会导致部分迭代未受保护
• 忘记在catch块中处理错误或记录日志，变成"沉默失败"
• 混合使用.then()和await导致错误处理路径混乱

2.3 全局兜底方案：unhandledrejection事件

对于可能遗漏的reject，应该设置全局捕获：

javascript复制// 浏览器环境
window.addEventListener('unhandledrejection', event => {
  event.preventDefault() // 阻止默认控制台警告
  trackError(event.reason)
  showFallbackUI()
})

// Node.js环境
process.on('unhandledRejection', (reason, promise) => {
  logger.critical('Unhandled rejection at:', promise, 'reason:', reason)
  // 可能需要graceful shutdown
})

重要提示：

• 生产环境必须实现这个兜底方案
• 在全局处理器中应该记录完整错误上下文
• 避免在处理器中抛出新错误（会导致无限循环）

2.4 高级模式：错误边界与重试机制

对于关键业务逻辑，可以实现更健壮的错误处理：

javascript复制const withRetry = (fn, retries = 3) => async (...args) => {
  let lastError
  for (let i = 0; i < retries; i++) {
    try {
      return await fn(...args)
    } catch (error) {
      lastError = error
      if (i < retries - 1) {
        await new Promise(r => setTimeout(r, 1000 * (i + 1)))
      }
    }
  }
  throw lastError
}

// 使用示例
const fetchWithRetry = withRetry(fetchData)

这种模式特别适合：

• 网络不稳定的移动端场景
• 对第三方API的调用
• 需要指数退避的重试策略

3. 实战中的典型错误场景解析

3.1 并行操作中的错误传播

使用Promise.all时，一个reject会导致整个Promise立即reject：

javascript复制// 错误示例 - 一个失败全部失败
Promise.all([fetchA(), fetchB(), fetchC()])
  .then(([a, b, c]) => { ... })
  .catch(error => {
    // 无法区分是哪个请求失败
  })

// 改进方案 - 让所有Promise都settle
Promise.allSettled([fetchA(), fetchB(), fetchC()])
  .then(results => {
    const errors = results.filter(r => r.status === 'rejected')
    if (errors.length) {
      handlePartialFailure(errors.map(e => e.reason))
    }
    return results.filter(r => r.status === 'fulfilled')
  })

3.2 回调函数中未处理的reject

这种隐蔽的错误经常出现在事件监听器中：

javascript复制// 危险代码！
button.addEventListener('click', () => {
  fetchData().then(data => {
    if (!data) throw new Error('No data')
    updateUI(data)
  })
  // 这里缺少.catch()
})

// 正确写法
button.addEventListener('click', () => {
  fetchData()
    .then(validateData)
    .then(updateUI)
    .catch(showErrorToast)
})

3.3 async函数隐式返回Promise的问题

async函数总是返回Promise，这可能导致意外的未捕获reject：

javascript复制async function init() {
  throw new Error('Oops') // 会被包装成rejected Promise
}

// 调用方忘记处理
init() // 未捕获的reject！

// 正确方式
init().catch(e => console.error('Init failed:', e))

4. 企业级解决方案与监控体系

4.1 错误分类处理策略

应该根据错误类型采取不同处理方式：

4.2 全链路错误追踪实现

集成Sentry/Bugsnag等工具的推荐配置：

javascript复制// sentry初始化
Sentry.init({
  dsn: 'YOUR_DSN',
  integrations: [
    new Sentry.Integrations.OnUncaughtException(),
    new Sentry.Integrations.OnUnhandledRejection()
  ],
  beforeSend(event) {
    if (event.exception?.values?.[0]?.type === 'NetworkError') {
      // 对网络错误特殊处理
      event.tags = { ...event.tags, specialHandling: 'retry' }
    }
    return event
  }
})

// 封装安全fetch
const safeFetch = async (url, options) => {
  try {
    const transaction = Sentry.startTransaction({ name: `fetch ${url}` })
    const response = await fetch(url, options)
    if (!response.ok) throw new Error(`HTTP ${response.status}`)
    return response
  } catch (error) {
    Sentry.captureException(error, { 
      tags: { apiEndpoint: url }
    })
    throw error // 继续向上传播
  }
}

4.3 测试策略与Mock方案

使用Jest测试Promise错误处理的推荐模式：

javascript复制describe('Promise rejection测试', () => {
  it('应该正确处理fetch失败', async () => {
    // Mock一个rejected Promise
    global.fetch = jest.fn().mockRejectedValue(new Error('Network error'))
    
    // 验证是否抛出特定错误
    await expect(loadData()).rejects.toThrow('Network error')
    
    // 验证错误是否被记录
    expect(mockLogger.error).toHaveBeenCalledWith(
      expect.objectContaining({ message: 'Network error' })
    )
  })

  it('未捕获的reject应该触发全局处理器', () => {
    const mockHandler = jest.fn()
    window.addEventListener('unhandledrejection', mockHandler)
    
    // 故意制造未捕获的reject
    Promise.reject(new Error('test'))
    
    // 需要延迟断言
    setTimeout(() => {
      expect(mockHandler).toHaveBeenCalled()
    }, 0)
  })
})

在团队协作中，建议将Promise错误处理纳入Code Review清单：

1. 每个async函数是否有try-catch或返回的Promise被处理？
2. 事件监听器中的异步操作是否妥善处理了错误？
3. Promise.all是否考虑了部分失败的情况？
4. 是否设置了全局unhandledrejection监听器？
5. 关键业务操作是否有重试或降级机制？