如何翻译Lighthouse Server错误？客户端与服务端哪种实现更优

没有绝对的放客户端还是服务端的标准答案，结合你用的vue-apollo技术栈，优先选「服务端返回标准化错误码+客户端映射翻译」的混合方案，以下是具体对比和落地方式：

两种纯实现方案的优劣势 #

• 纯服务端翻译
  • 优点：所有调用方（Web端、App端、第三方接口调用方）拿到的错误直接是目标语言，多端不需要重复维护翻译逻辑，不会出现同个错误多端翻译不一致的问题；服务端可以直接拿到错误关联的动态参数（比如校验失败的字段、数值阈值），拼接文案更准确。
  • 缺点：需要服务端额外做语言识别（一般通过请求头Accept-Language传递当前语言），如果服务端本身没有搭建i18n体系，改造成本偏高；前端如果要调整文案风格、做定制化提示，灵活性不足。
• 纯客户端翻译
  • 优点：不需要改动服务端逻辑，前端可以完全自主控制文案内容、提示样式和触发时机，能直接和前端已有的i18n体系打通。
  • 缺点：多端场景下每一端都要单独维护错误码和翻译文案的映射表，后续服务端新增错误类型很容易出现某端漏更新的问题；如果错误带服务端动态参数，需要额外约定参数返回格式，处理不当很容易出现文案拼接错乱；第三方调用接口时拿不到翻译后的文案，需要重复实现翻译逻辑。

vue-apollo 技术栈下的落地实现 #

Lighthouse 本身原生支持在GraphQL错误的extensions字段扩展自定义内容，配合Apollo的全局错误链路可以非常低成本实现统一翻译：

1. 服务端只需要做轻量改造：所有抛出的错误不再直接返回拼接好的文案，统一返回固定结构，包含唯一错误码、错误关联的动态参数、仅用于调试的原始错误信息即可，不需要内置翻译逻辑。
2. 客户端在Apollo客户端初始化时，添加全局错误拦截链路，统一处理所有GraphQL错误：

import { ApolloClient, InMemoryCache, ApolloLink, from } from '@apollo/client/core'
import { onError } from '@apollo/client/link/error'
import i18n from './i18n' // 项目内已引入的vue-i18n实例

// 错误处理拦截链路
const errorLink = onError(({ graphQLErrors, networkError }) => {
  if (graphQLErrors?.length) {
    graphQLErrors.forEach(error => {
      const errorCode = error.extensions?.code
      const errorParams = error.extensions?.params || {}
      if (errorCode) {
        // 匹配i18n配置里的对应错误文案，传入动态参数做插值
        const errorMessage = i18n.t(`errors.${errorCode}`, errorParams)
        // 这里触发全局提示，比如用UI库的Message组件弹出错误提示
        console.log(errorMessage)
      }
    })
  }
  if (networkError) {
    // 单独处理网络类错误，比如断网、请求超时
    console.log(i18n.t('errors.network_error'))
  }
})

// 把错误链路加入Apollo链路集合
const apolloClient = new ApolloClient({
  link: from([errorLink, /* 其余httpLink等链路 */]),
  cache: new InMemoryCache()
})

3. 翻译文案统一维护在vue-i18n的语言包内，和全站其他文案的多语言逻辑保持一致，切换语言时不需要额外重新请求接口。

这种方案兼顾了两边的优势：服务端只需要维护错误码定义，改造成本极低；客户端完全掌控翻译逻辑，和现有技术栈适配度高，也不会出现多端翻译不一致的问题。

内容的提问来源于stack exchange，提问作者ali asghar sadat fakhr