类型防护与Typescript中的Nullable对象声明之间的区别

最近，我在一个较大的角度项目中发现了一些打字稿代码，该项目的对象声明中包含Bitwise-OR / Pipe-Symbol。像这样：

dataSource: FileSource | null;

以我的理解，它是FileSource类型的对象，该对象也可以为null。

dataSource = null; // Works
dataSource = new FileSource... // Works
dataSource = 32; // Error

我还发现，您可以像这样声明一组完整的数据类型的对象：

myVariable: number | string | null;

现在是我的实际问题：我也可以声明带有问号的对象作为可为空的符号。这两个声明之间有什么区别吗？

myVariable: FileSource | null;
mySecondVariable?: FileSource;

如果这两者之间没有区别，您会认为这是一种不好的做法，因为这在其他语言中并不常见，并且没有有效的Javascript代码？

顺便说一句：在Javascript中：

myVariable: Number | null;
myVariable = "Hello World";

会没事的。

我的重点是对象的可空性以及这些声明的不同之处

这两个声明之间有什么区别吗？

是的，尤其是对于严格的null检查。要求具有联合类型（|符号）的属性的值必须与其中一种类型匹配。

一个可选的财产（以申报?）就是：可选。完全不需要该对象。尽管这样说，但在目前（至少），TypeScript的处理方式prop?: X完全相同prop: X | undefined；请参见jcatz指出的此问题。

如果没有严格的null检查，那就很好了：

type A = {
    dataSource: Date | null
};
type B = {
    dataSource?: Date
};

const a: A = { dataSource: null }; // Works
const b: B = { dataSource: null }; // Also works

使用严格的空检查，第二个错误：

type A = {
    dataSource: Date | null
};
type B = {
    dataSource?: Date
};

const a: A = { dataSource: null }; // Works
const b: B = { dataSource: null }; // Error: Type 'null' is not assignable to type 'Date | undefined'.

操场上的现场例子

类似地，undefined如果没有严格的null检查，则分配会很好，但是有了它们，在联合类型情况下会出错：

type A = {
    dataSource: Date | null
};
type B = {
    dataSource?: Date
};

const a: A = { dataSource: undefined }; // Error: Type 'undefined' is not assignable to type 'Date | null'.
const b: B = { dataSource: undefined }; // Works

操场上的现场例子