使用 Typescript 3.7空值合并运算符被介绍了。对于像这样的情况，它似乎是完美的类型保护
const fs = (s: string) => s
const fn = (n: number) => n
let a: string | null | undefined
let b: number | null | undefined
const x = (a ?? null) && fs(a)
const y = (b ?? null) && fn(b)
但是如果你将该代码放入打字稿游乐场，它会提醒您传递给 fs / fn 函数的 a 和 b 参数，例如：
I experimented a bit further and found it is not only an issue isolated to the nullish coalescing operator, but couldn't bend my mind around when typescript is able to use soemthing as a typeguard and when not (below you find some examples)
最后两行最让我困惑。在我看来，分配给 x7 和 x8 的两个表达式是完全等效的，但是在分配给 x8 的表达式中，类型保护起作用，但对于 x7 表达式中的 typescript 来说似乎不行：
const fs = (str: string) => str
const create = (s: string) => s === 's' ? 'string' : s === 'n' ? null : undefined
const a: string | null | undefined = create('s')
const b: string | null | undefined = 's'
let x
if (a !== null && a !== undefined) {
x = a
} else {
x = fs(a)
}
const x1 = a !== null && a !== undefined && fs(a)
const x2 = a !== null && a !== void 0 && fs(a)
const x3 = (a ?? null) && fs(a)
const x4 = (b ?? null) && fs(b)
const x5 = a !== null && a !== undefined ? a : fs(a)
const something = a !== null && a !== undefined
const x6 = something ? a : fs(a)
const x7 = something && fs(a)
const x8 = (a !== null && a !== undefined) && fs(a)
我不确定打字稿是否由于某种原因无法应用类型保护，或者它实际上是打字稿中的一个错误。那么是否存在某种规则手册，什么时候 typescript 可以应用 typeguard，什么时候不可以呢？或者这可能是一个错误？或者还有其他原因导致我无法编译这些示例吗？
顺便提一句。当使用用户定义的类型保护时，当然可以完美地工作，但最好不必为类型保护添加一些运行时代码来工作。
我花了很长时间试图写出为什么特定表达式的机械解释，例如expr1 || expr2 && expr3在某些情况下充当类型保护程序，而在其他情况下则不充当类型保护程序。它最终变成了几页，但仍然没有考虑到示例中的所有情况。如果你关心的话，你可以看看实现的代码表达式运算符 in 微软/TypeScript#7140.
关于为什么存在这种限制和类似限制的更高级的解释：当您，一个人，看到联合类型的值时，您可以通过想象如果该值缩小到每个成员会发生什么来决定分析它该类型的，对于该值存在的整个范围。如果您的代码对于每个此类案例分析都表现良好，那么它对于完整联合也表现良好。这个决定大概是根据您对相关代码的行为的关心程度，或者我们不希望编译器重现的其他一些认知过程来做出的。
编译器可能会进行此分析每时每刻，对于它遇到的每个可能的联合类型表达式。我们可以称之为“自动分布式控制流分析”，它的好处是几乎总是产生您想要的类型保护行为。缺点是编译器需要的内存和时间超出了您愿意花费的内存和时间，并且可能超出了人类能够花费的内存和时间，因为每个附加的联合类型表达式都会对所需的值产生乘法效应，从而导致组合爆炸。资源。指数时间算法并不适合好的编译器。
有时我希望能够hint向编译器告知应以这种方式分析特定范围内的特定联合类型值，我什至提出了此类“选择加入分布式控制流分析”的请求，（请参阅微软/TypeScript#25051），但即使这样也需要大量的开发工作来实现，并且会偏离启用 JS 设计模式而不需要开发人员过多考虑控制流分析的 TS 设计目标。
因此，最终，TypeScript 语言设计者所做的就是实现启发式算法，在有限的范围内执行此类分析，从而使传统的 and 惯用语JavaScript 编码模式。如果代码像(a ?? null) && fs(a)对于语言设计者来说，它被认为不够惯用和传统（这部分是主观的，部分取决于对现实世界代码的语料库的检查），并且如果实现它会导致重大的编译器性能损失，那么我不希望语言来支持它。
一些例子：
TS4.4 更新；以下固定在微软/TypeScript#44370微软/TypeScript#12184：支持将类型保护的结果“保存”为常量（就像你的something例如）以供以后使用。这是一个标记为“重新访问”的开放建议，语言架构师不祥地宣称很难以高性能的方式做到这一点。这可能是惯用的，但可能很难有效实施。
微软/TypeScript#37258：支持连续类型保护，其中同时对多个相关变量执行缩小。它的关闭过于复杂，因为为了避免指数时间算法，您需要将其硬编码为一些少量的检查，这通常不会很有用。语言维护者的建议：使用更惯用的检查。
这是我能得到的最接近权威或官方答案的答案。希望能帮助到你;祝你好运！