如何解决Angular 5中TypeScript编译错误TS2339：类型{}不存在errorValue属性

嘿，这个报错我太熟悉了！本质上是TypeScript的强类型检查在起作用——它没办法确定你传入的err对象里确实存在errorValue这个属性，所以直接抛出了TS2339错误来阻止潜在的运行时问题。下面给你几个实用的解决办法，按推荐程度排序：

1. 定义明确的错误接口（最推荐，符合TypeScript最佳实践） #

既然你知道Rest Service返回的是自定义结构的错误对象，那不如给它定义一个清晰的TypeScript接口，让编译器明确知道这个错误的结构：

// 先定义错误对象的接口，根据你实际的返回结构补充属性
interface RestErrorResponse {
  errorValue: {
    // 这里可以写具体的子属性，比如code?: number, message?: string
    [key: string]: any; // 如果结构不确定，用索引签名兜底
  };
  // 其他可能的顶层属性也可以在这里定义
}

// 然后修改你的错误处理函数参数类型
private myErrorHandler(err: RestErrorResponse): string {
  // 现在访问err.errorValue完全不会报错，还能获得代码提示
  const targetError = err.errorValue;
  // 你的switch逻辑...
  return '对应的i18n键';
}

这种方式既保证了类型安全，又能让IDE提供代码提示，后续维护也更清晰。

2. 类型断言（快速临时解决） #

如果你只是想快速绕过类型检查，确定这个err一定包含errorValue，可以用类型断言告诉TypeScript“我比你更清楚这个变量的类型”：

方式一：as语法（Angular项目更常用） #

private myErrorHandler(err: any): string {
  const errorValue = (err as any).errorValue;
  // 你的逻辑...
}

方式二：尖括号语法 #

private myErrorHandler(err: any): string {
  const errorValue = (<any>err).errorValue;
  // 你的逻辑...
}

⚠️ 注意：这种方式会关闭TypeScript对这个属性的类型检查，如果后端返回的结构后续发生变化，可能会导致运行时错误，所以只建议临时用用，长期来看还是定义接口更好。

3. 类型守卫 + 可选链（更严谨的容错方案） #

如果你不确定err是否一定包含errorValue（比如后端可能返回不同结构的错误），可以用类型守卫让TypeScript认可你的属性访问，再配合可选链避免运行时报错：

private myErrorHandler(err: any): string {
  // 类型守卫：检查err里是否有errorValue属性
  if ('errorValue' in err) {
    // 这里TypeScript会自动推断err包含errorValue属性
    const errorContent = err.errorValue;
    // 你的switch逻辑...
  }

  // 或者用可选链直接访问，避免属性不存在时的报错
  const errorContent = err?.errorValue;
  if (errorContent) {
    // 处理存在的情况
  } else {
    // 处理不存在的情况，返回默认错误键
    return 'common.error.unknown';
  }
}

这种方式兼顾了类型安全和运行时容错，适合错误结构不固定的场景。

补充：为什么用any还会报错？ #

有时候即使你把参数定义为any，TypeScript的严格类型检查（比如strictNullChecks开启时）还是会根据上下文推断出更具体的类型（比如如果你的HTTP请求返回的是默认的错误对象，编译器可能会把它推断为{}类型）。这时候就需要上面的方法来明确告诉编译器变量的真实结构。

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