TypeScript类型断言与非空检查逻辑疑问：为何部分场景不报错？

这个问题的核心在于TypeScript对类型断言的检查逻辑——它并不是完全放任开发者的所有断言，而是会区分「完全不可能的类型转换」和「存在潜在合理性的类型转换」：

1. 为什么返回字符串的断言会报错？ #

当你尝试把返回string的函数断言成返回number的Counter类型时：

type Counter = (start: number) => number;
let counterProblemDetected = ((start: number) => "yo") as Counter; // 此处TypeScript会报错

TypeScript判定string和number是完全不相交的原始类型，两者之间没有任何重叠的可能性，这种断言属于「明显不可能的类型转换」，所以会直接抛出错误，帮你避免低级的类型误用。

2. 为什么无返回值的断言不报错？ #

当strictNullChecks开启时，无返回值的函数实际返回undefined，而undefined确实不能直接赋值给number类型（这就是直接指定类型时报错的原因）：

// TypeScript报错：'void'不可赋值给number类型
let counterProblemDetected: Counter = ((start: number) => {})

但在类型断言的场景下，TypeScript认为这种转换存在潜在的合理性：

• 在JavaScript中，无返回值的函数本身就会返回undefined，而开发者使用断言时，TypeScript会默认你清楚自己的意图——比如你可能后续会修改这个函数让它返回number，或者你在处理一些运行时会动态返回值的特殊场景。
• 不同于string和number完全不相交，undefined和number在类型系统中属于「有间接关联的类型」（比如关闭strictNullChecks时undefined可以直接赋值给number），所以TypeScript不会把这种断言判定为「完全荒谬的转换」，因此允许你绕过常规的类型检查。

简单来说：TypeScript对类型断言的限制是只阻止完全不可能、毫无道理的转换，而对于那些虽然不符合常规类型兼容性，但存在一丝合理性（或开发者可能有特殊需求）的转换，会网开一面。

内容的提问来源于stack exchange，提问作者J-B