生产与开发环境中.catch处理console.error的最佳实践是什么

异步请求catch异常处理最佳实践 #

你当前的写法存在两处明显可优化的点：仅打印无业务兜底逻辑、硬编码console.error不符合lint规则也不利于多环境日志管理，具体优化规范如下： #

1. 补充业务兜底逻辑 #

异常捕获不能只做日志打印，需要和业务逻辑配套做容错处理，你当前的支付ID获取场景，异常发生时需要清理脏存储、给用户反馈、返回明确的失败标识供上层逻辑判断，调整后的代码示例：

const getPayIdResult = await fetch(url, options)
    .then(res => res.json())
    .then(json => {
      const payID = json.data.id
      sessionStorage.setItem('payID', payID)
      return { success: true, data: payID }
    })
    .catch(err => {
      // 统一日志上报
      logError('支付ID获取失败', err)
      // 业务兜底处理
      sessionStorage.removeItem('payID')
      showToast('支付信息获取失败，请稍后重试')
      return { success: false, error: err }
    })

2. 封装统一日志工具替代硬编码console #

不要在业务代码中直接写console.error，单独封装一层公共日志工具，既可以绕开lint的console使用限制，也可以统一控制不同环境的日志输出逻辑：

/* eslint-disable no-console */
// 公共日志工具文件，单独配置lint豁免，禁止业务代码直接调用console
export const logError = (...logArgs) => {
  // 开发、预发布环境输出到控制台，方便调试
  if (['development', 'staging'].includes(process.env.NODE_ENV)) {
    console.error(...logArgs)
  }
  // 全环境上报到错误监控平台，用于线上问题排查
  // reportToMonitor(logArgs)
}

3. 多环境日志策略说明 #

• 开发、预发布环境：必须保留控制台打印逻辑，同时可以开启错误栈输出，方便调试和测试阶段定位问题
• 生产环境：不需要移除日志逻辑，关闭控制台打印即可，改为上报到错误监控系统，既避免敏感信息泄露、减少不必要的性能损耗，也能留存线上错误记录用于问题排查

4. Lint规则适配方案 #

如果项目lint规则禁止console语句，只需要给上述公共日志工具文件单独添加lint豁免规则即可，不要全局关闭no-console规则，避免业务代码随意散写console语句。 #

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