可选链与非空断言深度解析：杜绝空值处理误用

最近在帮团队做前端代码评审，发现一个很有意思的现象：?.和!这两个操作符用的人越来越多，但真正能说清楚它们各自边界的人却没几个。很多人写代码时觉得都行，结果要么用!把运行时错误硬生生压下去，要么一个长长的?.?.?.?.链把可读性全毁了。这篇就专门把可选链（optional chaining）和非空操作符掰开揉碎讲一遍，包括它们各自的运行时表现、编译期行为、组合使用时的坑，以及我在实际项目中沉淀下来的选型习惯。如果你是写 TypeScript/JavaScript 的，尤其是刚接触 TS 不久、经常被类型报错折磨的开发者，这篇应该能帮你省下不少排查时间。

1. 从一个经典的 undefined 报错说起：为什么我们需要可选链

我先还原一个特别常见的场景。假设你在做商品列表页，接口返回的数据结构长这样：

// 接口返回 const product = { sku: "P-1001", stock: { warehouse: { city: "上海", quantity: 200, }, }, };

然后你在模板里要取城市名，写了product.stock.warehouse.city。一切看起来很正常，直到某天后端下架了这个商品，返回的product.stock变成了null，页面直接白屏，控制台报错：Cannot read properties of null (reading 'warehouse')。

这种情况，传统做法只有两种：一层层判空，或者用 lodash 的_.get。判空的代码长什么样？

const city = product && product.stock && product.stock.warehouse ? product.stock.warehouse.city : "";

说实话，这个还算是干净的。如果层级再深一点，比如product.stock.warehouse.manager.phone，这种写法直接变成灾难。我见过有人写product && product.stock && product.stock.warehouse && product.stock.warehouse.manager这种一眼望不到头的表达式，中间任何一个字段拼写错了都很难查。

可选链就是来终结这种防御性写法的。它允许你在访问属性链的时候，遇到null或undefined直接短路，返回undefined，后面整条链不再继续求值。上面那个例子，一行搞定：

const city = product?.stock?.warehouse?.city ?? "";

product如果是null，这一整个表达式直接返回undefined，根本不会去访问.stock。这对于接口数据、深层配置对象、第三方 SDK 返回结果这些“外部传入”的数据来说，等于多了一层结构化的安全带。

但要先说清楚一个原则：可选链解决的是“值可能存在，也可能不存在”的问题，不是让你无脑把所有属性访问都加上?.。这一点后面会细说。先记住它的核心特点：运行时有短路机制，编译时不需要额外类型标注，纯 JS 也能用。它是 ES2020 的标准语法，不是 TypeScript 的专利。

我自己的经验是，可选链最适合用在一个场景：数据是外部来的，结构不完全可控，缺少某一层不应该导致整个程序崩溃，而是应该优雅地返回undefined，后续再配合默认值处理。

2. 可选链的完整用法：不只是给点号加个问号

?.看着简单，但它一共有三种形态，很多人只用了第一种。

2.1 三种形态：属性访问、可选下标、可选调用

第一种是静态属性访问，最常见：

const city = user?.address?.city;

第二种是动态下标访问，用?.[]：

const list = data?.items; const first = list?.[0]; // 数组第一项 const val = obj?.[key]; // 变量做键名

第三种是函数调用，用?.()：

const result = handler?.(payload); // handler 存在才调用

第三种在事件回调、插件机制里特别有用。比如你的组件接收一个可选的回调函数：

function Modal({ onClose }) { // onClose 可能没传，不能直接调用 onClose?.(); }

注意onClose?.()和onClose()的区别：前者在onClose为null/undefined时静默跳过调用，返回undefined；后者直接抛TypeError。这个差异就是整个可选链最核心的语义。

2.2 短路机制：停止求值意味着什么

可选链的短路不是一个简单的“返回 undefined”，它还意味着链上剩余部分的副作用代码不会执行。举个比较极端的例子：

let i = 0; const obj = null; const result = obj?.items[i++]; console.log(i); // 仍然是 0

因为obj是null，?.短路后，后面的[i++]根本不会求值，i不会自增。这一点在写表达式时容易忽略，但理解后可以避免一些诡异的 bug。

更有意思的是，可选链对delete操作也支持：

delete user?.profile?.address;

即使user.profile不存在，这个表达式也不会报错，返回true。

2.3 几个容易踩的语法坑

虽然?.好用，但它不是万能的。我总结几个真实项目中容易犯的错。

第一个坑：可选链不能用在赋值目标左边。

obj?.name = "Tom"; // SyntaxError

这个逻辑其实很容易理解：如果obj是null，你往哪儿赋值？语言直接把这个场景定义成语法错误，避免产生“赋值到 undefined”这种更隐蔽的运行时问题。正确做法是先判断或者用空值合并兜底。

第二个坑：可选链不能用来检测一个未声明的变量。

// 这会抛 ReferenceError，而不是返回 undefined console.log(notExist?.name);

有人以为notExist?.name能像typeof notExist一样安全，实际上不行。notExist本身未声明时，走到这个表达式就已经抛错了。想检测全局变量是否存在，规范的写法还是typeof。

第三个坑：可选链的优先级相对较低，和new、逻辑运算符混用时要加括号。

// `new a?.b()` 实际是 `new (a?.b)()`，不是 `(new a)?.b()` const obj = new a?.b(); // 可能不是你想要的意思 // 和逻辑运算混合时，最好显式加括号 const x = (a?.b) || c;

日常开发中我强烈建议：凡是?.和其他运算符混用的情况，一律用括号把可选链表达式包起来，别人读代码轻松，你自己也不会理解错。

2.4 转译与兼容性

可选链是 ES2020 标准，如果目标浏览器不支持，需要借助编译器转译。Babel 需要@babel/plugin-proposal-optional-chaining（现在并入 preset-env 了），TypeScript 3.7 以上直接原生支持。转译后的代码会用临时变量保存中间结果，本质上是在模拟短路语义。这个开销非常小，基本可以忽略，但如果你做的是极高性能敏感的场景，心里有个数就行。真正要注意的是：转译产物里会多出一些_a === null之类的判断，调试时看代码不如原版优雅。

到这里，可选链本身该讲的基本讲完了。但只讲?.还远不够，因为开发中真正让人迷惑的是它和 TypeScript 的非空断言操作符!之间的关系。很多 TS 新手会把两个语法混着用，甚至搞不清为什么要设计这两个东西。

3. 非空断言操作符：一个“我比编译器懂”的强指令

如果说可选链是“运行时主动判断”，那么非空断言就是“编译期强制承诺”。它是 TypeScript 特有的语法，JavaScript 里没有这个东西。写法是在表达式末尾加一个感叹号：

const el = document.getElementById("app")!;

3.1!到底做了什么

先理解类型层面。document.getElementById的类型签名是：

getElementById(elementId: string): HTMLElement | null;

如果不开非空断言，el的类型是HTMLElement | null，你访问el.style编译器立刻报错：el 可能是 null。加上!之后，el的类型被断言为HTMLElement，编译器闭嘴，后续访问属性不再报错。

关键是，!是纯编译期行为。它不会生成任何 JavaScript 代码，不会做运行时判断。你编译出来的 JS 里，el前面没有任何保护：

const el = document.getElementById("app"); // 后续操作照常执行，运行时如果 el 真是 null，该炸还是炸

所以非空断言的本质是：你在告诉 TypeScript 编译器，“这里我确定不会是空的，你类型检查就不用管了”。它削掉的是类型错误，不是运行时错误。

3.2 什么时候用!是合理的

我观察到一个规律：很多开发者用!是为了让编译器闭嘴，而不是因为真正确信这里不会为空。这两种动机区分开很重要，因为前者往往会在运行时埋雷。

合理的使用场景通常符合这个特征：值在类型上可能是null/undefined，但当前执行路径下可以“局部证明”它一定非空。举几个我常写的例子。

第一种，从Map或Set里取出之前已经set过的值：

const cache = new Map<string, User>(); function loadUser(id: string) { const cached = cache.get(id); if (cached) { return cached; // 这里类型收窄过了，不需要 ! } const user = fetchUser(id); cache.set(id, user); return user; }

上面这个例子其实连!都不用，因为if (cached)已经把undefined分支收窄掉了。真正需要!的场景是那种“语义上一定存在，但类型上表达不出来”的时候。

第二种，find之后确定元素存在：

const items: string[] = ["a", "b", "c"]; const target = items.find((item) => item === "b")!;

find的返回类型天然包含undefined，但如果业务逻辑上你已经确认目标一定在数组里，这里加!是合理的。

第三种，DOM 操作里确定元素一定存在：

const submitBtn = document.querySelector("#submit")!;

页面模板里有这个 id，运行时一定查得到，用!可以避免每次submitBtn?.addEventListener这种罗嗦写法。

这些例子的共同点是：程序员对运行时状态的把握，比类型系统更精确。操作符在这里把“类型系统无法表达的信息”补充进去了。

3.3 滥用!的代价：从编译错误变成运行时事故

很多问题就出在那些“自以为一定存在”的场景上。页面结构变了、接口字段改了、时序调整了，!后面的代码就会在运行时炸出各种Cannot read properties of undefined，而且炸的位置通常离数据源很远，排查成本高。

一个非常典型的反面例子，在函数参数上滥用：

function sendMessage(user: User | undefined) { const name = user!.name; // 万一 user 真是 undefined 呢 console.log(name); }

这种写法完全抛弃了类型系统的保护。如果user可能没传，你应该在入口处做判断并走兜底逻辑，而不是用!让自己暂时“眼不见心不烦”。

还有一个细节需要特别注意：!只是断言当前表达式非空，不代表整个链上的后续路径都安全。比如：

const a: { b?: { c: string } } = ...; const value = a!.b.c; // 如果 b 不存在，照样报错

a!只解决了a本身可能为 null 的问题，b还可能不存在。想要安全访问，正确的做法是a?.b?.c或者a?.b!.c（等于是：如果a为空则短路，否则断言b非空再访问c）。

3.4 非空断言和可选链：一个管编译一个管运行

把两者放在一起对比就非常清楚了：

这个对比图基本就是全文的骨架了。?.是防御性的，担心值不存在，所以主动检查；!是独断性的，确信值存在，所以绕过检查。两者不是替代关系，而是适用于不同假设。

我个人的经验法则是：当“值是否存在”取决于程序状态时，用?.；当“值是否合法”在类型系统里表达不出来时，用!。前者是常态，后者才是例外。

4. 别忘了空值合并操作符??：和?.的最佳拍档

?.返回undefined，那“undefined 时给个默认值”的需求自然就来了。这时候很多新手会直接拿||处理，但这里藏着一个经典陷阱。正确选择的空值合并操作符??经常被归到“非空操作符”这个类别里聊，所以这篇也把它一起讲透。

4.1??和||的本质差异

||的语义是：左侧为 truthy 时返回左侧，否则返回右侧。注意，是 truthy，不是“非空”。也就是说，0、""、false、NaN这些 falsy 值，都会让||走到右侧。

??的语义是：左侧为null或undefined时返回右侧，其他情况一律返回左侧。换言之，它只对空值起反应，不会误伤0、false、空字符串。

看个实际案例。你写了一个优惠金额展示逻辑：

const discount = order.discount ?? 0;

这里的discount理想行为是：订单里没有折扣字段时显示 0，折扣本身就是 0 时也必须显示 0。如果写成order.discount || 0，结果同样满足。但换个场景：

const count = cart.itemCount ?? 0;

itemCount如果是 0（购物车确实是空的），|| 0会先把 0 转成默认值 0，碰巧结果一样；但如果默认值是“去结算”这类状态标志，或者干脆是10，那||就会把真实的 0 吞掉，变成假的默认值。

const threshold = config.limit ?? 10; // limit 为 0 时，希望得到 0，而不是 10

所以凡是“默认值仅针对空值生效”的场景，都应该用??，而不是||。这是个非常容易犯的错误，尤其是在处理数字、布尔值、空字符串这些“合法但 falsy”的数据时。

4.2??的语法限制：不能直接和||/&&混合

??有个比较特殊的语法规则：禁止与||、&&在同一表达式中无括号混用。

const x = a ?? b || c; // SyntaxError

原因是??和||、&&的优先级相似，如果混用会导致求值顺序产生歧义，语言设计者干脆把它声明为语法错误，逼你显式加括号：

const x = (a ?? b) || c; const y = a ?? (b || c);

这个限制看着烦，其实是保护你。我在实际代码里见过很多人为了省括号写出奇怪的逻辑，后面维护的人根本看不懂。

4.3?.与??的标准搭配

当数据链路某层可能缺失时，?.负责“安全访问”，??负责“缺失兜底”，组合起来非常自然：

const city = user?.address?.city ?? "未知城市";

user为空、address为空、city为 undefined，任何一种情况最终都能拿到默认值。这是业内最常见的组合用法，也是我要强烈推荐的标准写法。比起嵌套三元和一堆||，这种方式意图清晰得多。

还有种细节值得注意，就是当你只关心某个可能为空的函数是否存在时，可以和调用一起兜底：

const result = notifier?.notify?.(data) ?? "notify-not-called";

notifier为空，整个链短路返回undefined，然后被??捕获；notify方法存在但调用的返回值为空，同样被捕获。这里注意区分：使用?.()?.和??的组合，对返回值为空字符串或 0 的情况不会误触默认值，这是??的功劳。

4.4 空值合并与可选链的“假短路”问题

这里提一个我踩过的坑。?.和??虽然常在一起用，但它们的短路逻辑是独立触发的。看这句代码：

const age = user?.profile?.age ?? 18;

如果user.profile.age是0（比如刚注册的用户年龄字段填了 0，或者接口里age默认值就是 0），结果会是什么？我见过不少人凭直觉以为“age为假值，会被??替换成 18”。但正确答案是：age为0时，??不会起作用，结果就是0。因为??只对null/undefined触发，0不在其中。

这个行为其实是正确的，因为0是一个合法年龄值（面子上可能不太常见），不能被静默替换。但正因为这种“它看起来很像是要兜底”的错觉，容易让读代码的人误解逻辑。解决方法是：要么在数据解析层把age明确转换，要么在注释里写清楚“0 代表未设置”。我一般倾向后者，因为语义更直观。

5. 实战选型判断：什么场景用?.，什么场景用!，什么场景直接if

掌握了语法，最后还得解决“怎么写才算好代码”的问题。我把自己在项目里的选型标准整理成了一套判断顺序，每次不确定时都按这个走一遍。

5.1 一张表理清决策逻辑

5.2 宁可写if，也不要强行连串?.

可选链虽好，但很多人会从一个极端走到另一个极端：所有属性访问全部加上?.。比如：

const showName = data?.user?.info?.name?.toUpperCase();

假设data是必填参数，user一定存在，这些多余的?.不仅不会提升安全性，反而让读代码的人产生一个错误认知：这里每一层都可能为空。久而久之，整个代码库的类型保护形同虚设，后面接手的开发者看到?.密密麻麻，直接放弃理解数据流。

我通常的习惯是：只有“提供了默认值兜底”或“空值可接受继续往下走”这两种情况才用?.。如果空值会改变处理逻辑，直接写if判断，让分支显式化。比如：

if (!user?.profile) { // 渲染引导用户完善资料的 UI return <EmptyProfile />; } // 到这里，user.profile 一定存在，后面不需要再 ?. 了 const city = user.profile.city;

这种写法的额外好处是：一旦if收窄了类型，TypeScript 编译器会在后续代码中自动把user.profile视为非空，你甚至不需要!。

5.3 非空断言在代码评审中的红线

我评审代码时，看到!会格外神经质。不一定禁止，但一定会问几个问题：

第一，!的左侧是否是函数参数或外部传入的数据？如果是，大概率是滥用，应当改成入参校验或可选链。

第二，!是否存在于一个相对独立的小作用域里，且在该作用域内已经有显式的非空证明？比如上面find的例子，证明目标一定存在，这种情况我接受。

第三，团队里是否有约定俗成的例外清单？比如某些 DOM id 是页面骨架，声明了必有，这类可以统一放行。

一个非常有用的配置是 ESLint 里的@typescript-eslint/no-non-null-assertion规则。我建议团队把它设为warn，不阻断构建，但每个!都会在 CI 里亮黄灯，倒逼作者写下注释解释为什么敢这么用。这样既保留灵活性，又起到review提醒作用。

另外，在 TypeScript 配置里一定要开启strictNullChecks。不开启的话，null和undefined会被当成任意类型的子类型，那你根本感受不到?.和!存在的意义，类型系统直接沦为摆设。我见过很多老项目strict全关，代码里?.和!混用却毫无提示，这类项目的重构成本极高。

5.4 在数据边界收口，比到处?.更省心

最后分享一个更进阶的经验。如果你发现某个接口返回的数据结构复杂，而业务代码里到处都是?.链，很可能是数据访问层没有做“收口”。更好的做法是在获取数据之后，立刻把外部的松散结构转换为内部固定的数据模型。

type UserModel = { id: string; name: string; address: { city: string; zip: string; }; }; function toUserModel(raw: ApiUser): UserModel { return { id: raw.id, name: raw.name, address: { city: raw.address?.city ?? "未知城市", zip: raw.address?.zip ?? "000000", }, }; }

这样业务代码拿到的UserModel是完整可用的，访问user.address.city时根本不需要?.，即使原始接口漏字段，也已经在边界层兜底好了。这种做法比在几十个组件里各写各的?.可维护得多，也让?.只出现在“真正可能有数据缺失”的位置，而不是满天飞。

5.5 关于工具链转译的一个提醒

如果项目运行环境比较老，比如要兼容某些旧版鸿蒙 WebView 或低版本浏览器内核，使用可选链和空值合并时要注意编译配置。esbuild 和 Babel 默认会按 targets 自动降级，但如果你直接用 TSC 输出且把target设成ES2019及以下，TS 会帮你降级成辅助函数。这里有个性能层面的冷知识：可选链转译后生成的临时变量逻辑，在某些极端 hot path 上会有可测量的开销，但日常业务代码完全不用在意。

真正要小心的反而是另一种情况：团队成员本地是新型浏览器开发，编译目标设成了现代标准，代码里大胆用?.，结果线上低版本 WebView 没有这个语法，直接整段 JS 解析失败。这不是?.用法的问题，是构建配置没跟上。所以我建议统一用构建工具的targets配置来控制降级，而不是靠开发者自觉。

写在最后

代码写多了你会发现，?.、!、??这些操作符看似只是语法糖，背后其实是对“空值”这一状态的不同理解方式。可选链承认数据可能缺失，以防御的姿态让程序继续跑下去；非空断言假设数据一定存在，以信任的姿态换取类型系统的简化；而空值合并则在缺失发生时，帮你优雅地补上一个合理的默认值。三者没有优劣，只有合不合适。

我实际项目里踩过的最大一个坑，就是把!当成万能钥匙。当时用document.getElementById("root")!写了很多入口代码，一切正常。直到后来页面改版，某个功能被拆成了异步加载，root节点在脚本执行瞬间还没渲染出来，整个应用直接黑屏。那一刻我才真正理解非空断言的本质：它只是让你暂时绕过了类型检查，但运行时的那道坎，永远不会消失。

从那以后，我的习惯变成：拿不准该用?.还是!的时候，就选?.。因为从可维护性看，一个防御性的返回undefined比一个自信的运行时崩溃，留给后续排查的余地大太多了。如果你也正在和自己的代码里的空值搏斗，希望这篇能帮你少走几步弯路。