为什么在 TypeScript 中使用 `!` 时应该谨慎

Mar 15, 2026 · 2 min read

TypeScript 的空值安全特性是其最强大的卖点之一。启用 strictNullChecks 后,编译器会强制你在使用值之前处理可能为 null 或 undefined 的情况。但有一个单字符可以让你绕过所有这些检查:!。

当编译器报错时,非空断言操作符很容易被顺手使用。理解它实际做了什么——以及它没有做什么——将使你避免那些真正难以追踪的 bug。

核心要点

!(非空断言)操作符告诉 TypeScript 编译器将值视为非空,但它不会生成任何运行时检查——在生成的 JavaScript 中会被完全擦除。
过度使用 ! 会破坏 strictNullChecks 的目的,将编译时错误转化为运行时崩溃。
更安全的替代方案,如显式空值检查、可选链(?.)、空值合并(??)和自定义断言守卫应该是你的首选。
仅在你拥有编译器无法验证的真实外部知识时才使用 !,并将每个使用实例视为代码审查的标记。

TypeScript `!` 操作符实际做了什么

当你在表达式后附加 ! 时,你是在告诉 TypeScript 编译器:“相信我,这个值既不是 null 也不是 undefined。“编译器会从类型中移除 null 和 undefined,并停止报错。

// 启用 strictNullChecks 时
const input = document.querySelector('input') // 类型: HTMLInputElement | null
const value = input!.value // 类型: string — 编译器满意了

关键部分在于:**! 在生成的 JavaScript 中会被完全擦除。**没有运行时检查。没有守卫。没有安全网。如果 input 在运行时实际上是 null,你仍然会得到你一开始试图避免的 Cannot read properties of null 错误。

明确赋值断言 vs. 非空断言

! 操作符出现在两个不同的上下文中,值得将它们区分开来。

非空断言 — 用于表达式,从类型中剥离 null | undefined:

const el = document.getElementById('app')! // HTMLElement,而不是 HTMLElement | null

明确赋值断言 — 用于类字段或变量声明,告诉编译器属性会在使用前被赋值,即使它无法验证:

class UserService {
  user!: User // "我保证这会在读取前被赋值"
}

两者都是编译时断言,在不添加任何运行时保护的情况下让编译器静默。非空断言从表达式的类型中移除 null | undefined,而明确赋值断言禁用变量或类字段的明确赋值检查。

为什么过度使用 `!` 会破坏 TypeScript 的空值安全

! 操作符是一个逃生舱口,而不是解决方案。当你使用它时,你并没有修复空值问题——你只是将它从编译器中隐藏,同时让它在运行时完全保留。

一个导致真实 bug 的常见模式:

// 危险:假设元素总是存在
const button = document.querySelector('.submit-btn')!
button.addEventListener('click', handleSubmit)

如果该元素在特定上下文中不存在——不同的页面、条件渲染、测试环境——你会得到运行时崩溃。编译器没有给你任何警告,因为你告诉它不要警告。

值得优先使用的更安全替代方案

现代 TypeScript 具有强大的控制流分析。在许多开发者历史上使用 ! 的情况下,编译器现在可以通过简单的守卫自动收窄类型。

显式空值检查:

const button = document.querySelector('.submit-btn')
if (button) {
  button.addEventListener('click', handleSubmit)
}

可选链与空值合并:

const label = document.querySelector('label')?.textContent ?? 'Default'

类型守卫函数:

function assertExists<T>(
  val: T | null | undefined,
  msg: string
): asserts val is T {
  if (val == null) throw new Error(msg)
}

const el = document.getElementById('app')
assertExists(el, 'App element not found')
el.style.display = 'block' // 收窄为 HTMLElement

断言守卫方法特别有用,因为它保留了安全保证——如果值为 null,你会在失败点得到一个明确的、描述性的错误,而不是在下游某处出现神秘的崩溃。

何时 `!` 真正合适

确实存在合法的使用场景。如果你拥有编译器无法推断的外部知识——例如,由 TypeScript 无法追踪的初始化生命周期保证的值——! 是一个合理的工具。关键问题是:你是真的知道编译器不知道的东西,还是只是在消除警告?

如果是后者,警告可能是对的。

结论

TypeScript 的 ! 操作符不会让你的代码更安全——它只是让代码更安静。如果使用不当,它会将编译时错误转化为运行时崩溃,这与 strictNullChecks 旨在防止的情况正好相反。优先使用控制流收窄、可选链或显式守卫。仅在你拥有编译器无法验证的真实确定性时才使用 !,并将每个使用实例视为值得审查的代码审查标记。

常见问题

不会。感叹号在编译期间会被完全剥离。生成的 JavaScript 不包含任何空值检查或守卫。如果值在运行时实际上是 null 或 undefined,你的代码会抛出错误,就像你从未使用过 TypeScript 一样。

可能会。当你写 user!: User 这样的属性时,你是在告诉编译器该值会在任何代码读取它之前被赋值。如果这个假设是错误的——例如,如果预期的初始化步骤被跳过——访问该属性将返回 undefined,并可能导致运行时错误,而没有编译时警告。

当你拥有编译器无法验证的外部知识时是合理的。一个常见的例子是当值由 TypeScript 无法追踪的初始化生命周期保证时(例如,框架初始化钩子或依赖注入)。即使在这种情况下,也要考虑使用显式断言守卫,这样缺失的值会产生清晰的错误消息,而不是神秘的崩溃。

最佳替代方案取决于上下文。对于 DOM 查找和可选数据,使用可选链与空值合并。对于缺失值是真正错误的情况,使用抛出描述性消息的自定义断言守卫函数。这两种方法都保留了类型收窄,同时增加了真实的运行时安全性。

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.

核心要点

TypeScript ! 操作符实际做了什么