如何让TypeScript认可宽松接口到严格接口的合法类型转换？

问题复现 #

以下代码期望通过if (person.address)的条件校验，筛选出带地址的人员对象传入logAddress函数，但TypeScript编译失败：

interface Person {
  name: string,
  address?: string
}

interface PersonWithAddress extends Person {
  address: string
}

function tryLoggingAddresses(people: Array<Person>) {
  people.forEach(person => {
    if (person.address) {
      logAddress(person)
    }
  })
}

function logAddress(personWithAddress: PersonWithAddress) {
  console.log(personWithAddress.address)
}

编译报错信息：

error TS2345: Argument of type 'Person' is not assignable to parameter of type 'PersonWithAddress'.
      Types of property 'address' are incompatible.
        Type 'string | undefined' is not assignable to type 'string'.
          Type 'undefined' is not assignable to type 'string'.

    63       logAddress(person)

已知通过logAddress(person as PersonWithAddress)强制类型断言可以绕过编译，但该方案跳过了类型检查，存在类型安全隐患，需要无断言的安全实现方式。

问题原因 #

TypeScript的自动类型收窄仅作用于被判断的属性本身：当你判断person.address为真值时，TS只会推导当前代码块内person.address的类型为string，但不会自动将整个person对象的类型收窄为子接口PersonWithAddress，因此参数类型不匹配。

安全实现方案 #

方案1：自定义类型守卫（推荐，符合TS最佳实践） #

定义返回类型谓词的判断函数，明确告知TS符合校验逻辑的对象属于PersonWithAddress类型，TS会基于该谓词自动完成类型收窄：

// 类型守卫函数，返回值为类型谓词
function hasAddress(person: Person): person is PersonWithAddress {
  return typeof person.address === 'string'
}

function tryLoggingAddresses(people: Array<Person>) {
  people.forEach(person => {
    if (hasAddress(person)) {
      // 此处person自动收窄为PersonWithAddress类型，可直接传入
      logAddress(person)
    }
  })
}

该方案下类型判断逻辑完全可控，后续如果PersonWithAddress新增必填字段，TS会强制要求你更新守卫函数的判断逻辑，不会漏过类型错误。

方案2：构造符合接口约束的新对象（无需新增函数） #

如果不想额外定义守卫函数，可以在判断分支内（此时TS已确认person.address为string类型），直接构造符合PersonWithAddress约束的对象传入：

function tryLoggingAddresses(people: Array<Person>) {
  people.forEach(person => {
    // 用typeof判断代替真值判断，避免空字符串等边界场景误判
    if (typeof person.address === 'string') {
      logAddress({
        name: person.name,
        address: person.address
      })
    }
  })
}

提示：尽量避免使用as类型断言，断言本质是让编译器跳过类型校验，一旦后续接口字段变更、判断逻辑出现漏洞，TS不会给出任何错误提示，极易引发线上问题。

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