本教程深入探讨了 typescript 中处理未赋值变量进行真值检查时常见的类型错误。我们将解释为何将变量声明为 `object` 却未初始化会导致编译问题，并提供两种核心解决方案：使用 `object | undefined` 联合类型允许变量在赋值前为 `undefined`，或使用 `object | null` 并显式初始化为 `null`。通过这些方法，可以确保代码的类型安全和逻辑清晰。
理解 TypeScript 中未赋值变量的真值检查问题
在 JavaScript 中，一个变量即使未被赋值，也可以在条件语句（如 if 语句）中进行真值（truthy）检查。未赋值的变量默认为 undefined，undefined 在布尔上下文中被视为假值（falsy）。然而，当我们将 JavaScript 代码转换为 TypeScript 时，由于 TypeScript 的静态类型检查特性，这种行为可能会导致编译错误。
考虑以下 JavaScript 代码片段，它尝试获取一个账户对象，并在获取失败时执行重定向或登录操作，最后对 account 变量进行真值检查：
const accounts = state.msalInstance.getAllAccounts();
let account; // 未指定类型，默认为 any
if (accounts.length) {
account = accounts[0];
} else {
await state.msalInstance
.handleRedirectPromise()
.then(redirectResponse => {
if (redirectResponse !== null) {
account = redirectResponse.account;
} else {
state.msalInstance.loginRedirect();
}
})
.catch(error => {
console.error(`Error during authentication: ${error}`);
});
}
if (account) { // 在 JavaScript 中，account 未赋值时为 undefined，此处逻辑正常
// 执行相关操作
}当尝试将其转换为 TypeScript 并将 account 变量明确声明为 object 类型时，问题便浮现了：
const accounts = state.msalInstance.getAllAccounts();
let account: object; // 声明为 object 类型
if (accounts.length) {
account = accounts[0];
} else {
await state.msalInstance
.handleRedirectPromise()
.then((redirectResponse: { account: object; }) => {
if (redirectResponse !== null) {
account = redirectResponse.account;
} else {
state.msalInstance.loginRedirect();
}
})
.catch((error: { name: string; }) => {
console.error(`Error during authentication: ${error}`);
});
}
if (account) { // 编译错误: Variable 'account' is used before being assigned.
// 此处会报错，因为 TypeScript 无法保证 account 在此之前已被赋值为 object 类型
}TypeScript 编译器在此处报错，提示 Variable 'account' is used before being assigned. (变量 'account' 在赋值前被使用)。这是因为 let account: object; 告诉 TypeScript account 变量最终必须是一个 object 类型的值。然而，在某些执行路径中（例如 state.msalInstance.loginRedirect() 被调用，或者 redirectResponse 为 null 且没有 account 赋值给 account 变量），account 可能永远不会被赋值为一个 object。当 if (account) 进行真值检查时，TypeScript 无法确定 account 是否已经是一个有效的 object，或者它仍然是未赋值的 undefined 状态，这与 object 类型声明相悖。
解决方案：利用联合类型处理潜在的未赋值状态
要解决此问题，我们需要告诉 TypeScript account 变量在某些情况下可以不是一个 object，而是 undefined 或 null。这可以通过使用联合类型（Union Types）来实现。
方案一：使用 object | undefined 联合类型
最直接的解决方案是将 account 变量的类型声明为 object | undefined。这明确告诉 TypeScript，account 变量既可以是一个 object，也可以是 undefined。
const accounts = state.msalInstance.getAllAccounts();
let account: object | undefined; // 允许 account 为 object 或 undefined
if (accounts.length) {
account = accounts[0];
} else {
await state.msalInstance
.handleRedirectPromise()
.then((redirectResponse: { account: object; }) => {
if (redirectResponse !== null) {
account = redirectResponse.account;
} else {
state.msalInstance.loginRedirect();
}
})
.catch((error: { name: string; }) => {
console.error(`Error during authentication: ${error}`);
});
}
if (account) { // 编译通过
// 在此代码块中，TypeScript 知道 account 已经被赋值且不是 undefined，因此它是一个 object 类型。
// 可以安全地访问 account 的属性，例如 account.id
}通过将类型声明为 object | undefined，我们允许 account 在初始化前处于 undefined 状态。当 if (account) 条件被评估时，TypeScript 的控制流分析会理解，如果条件为真，那么 account 必然不是 undefined，因此它必须是 object 类型。
方案二：使用 object | null 联合类型并显式初始化
另一种常见的做法是将变量类型声明为 object | null，并显式地将其初始化为 null。这在语义上更明确地表示变量“没有值”的状态，而不是“未被赋值”的 undefined 状态。
const accounts = state.msalInstance.getAllAccounts();
let account: object | null = null; // 允许 account 为 object 或 null，并初始化为 null
if (accounts.length) {
account = accounts[0];
} else {
await state.msalInstance
.handleRedirectPromise()
.then((redirectResponse: { account: object; }) => {
if (redirectResponse !== null) {
account = redirectResponse.account;
} else {
state.msalInstance.loginRedirect();
}
})
.catch((error: { name: string; }) => {
console.error(`Error during authentication: ${error}`);
});
}
if (account) { // 编译通过
// 在此代码块中，TypeScript 知道 account 已经被赋值且不是 null，因此它是一个 object 类型。
// 可以安全地访问 account 的属性。
}这种方法与 object | undefined 类似，但它通过显式初始化 null 来提供更强的意图表达。在许多编程范式中，null 被用作表示“无值”的明确信号，而 undefined 通常表示“未定义”或“缺失”。在 if (account) 这样的真值检查中，null 和 undefined 都被视为假值，因此这两种方案在功能上是等效的。
注意事项与最佳实践
TypeScript 的严格空检查 (strictNullChecks)： 在 TypeScript 的 tsconfig.json 文件中，如果启用了 strictNullChecks（推荐启用），那么 null 和 undefined 将不再是任何类型的子类型，除非显式地将它们包含在联合类型中。这意味着 let x: string = null; 将会报错，而 let x: string | null = null; 才是正确的。本文中的解决方案正是基于 strictNullChecks 开启的情况。
-
undefined vs null：
- undefined 通常表示一个变量尚未被赋值，或者一个对象属性不存在。
- null 通常表示一个变量被明确地赋予了“无值”的状态。 选择哪一个取决于你的代码逻辑和团队约定。在实践中，两者都可以用于表示变量可能没有有效值的情况。
-
类型推断： 在某些简单场景下，TypeScript 可能会根据初始化值自动推断出联合类型。例如：
let data = null; // TypeScript 推断 data 的类型为 any let data: string | null = null; // 显式声明类型更佳
然而，当变量在声明时没有初始化，并且其值可能在多个分支中赋值时，显式声明联合类型是必不可少的。
总结
TypeScript 的类型系统旨在提高代码的健壮性和可维护性。当处理一个变量可能在某些执行路径中未被赋值的情况时，简单地声明为其最终类型（如 object）会导致编译错误。通过利用联合类型 object | undefined 或 object | null，我们可以准确地表达变量的潜在状态，从而满足 TypeScript 的类型安全要求，并使代码能够通过真值检查。选择哪种联合类型取决于项目的具体需求和编码习惯，但核心思想是明确告知编译器变量可能存在的“无值”状态。
