Optional chaining 在2019年12月达到 Stage 4，已包含于2020年6月发布的ES2020中。所以不存在「回炉重做」的可能性。




f?.()的语义是f === undefined || f === null ? undefined : f()，之前确实有过一些讨论，是否应为typeof f === 'function' ? f() : undefined，但绝大多数意见认为应该和 f?.x 和 f?.[x] 的语义保持一致，即 nullish check。我也认为应该如此。注意，从静态类型角度来说，判定是否nullish和是否是callable是两个不同的事情，不应混淆。someInterface.customMethod?.()中，如果someInterface上的customMethod并不是function或null和undefined，类型检查（TS或其他 type checker）就当然应该报错。

ypescript-eslint/no-unused-expressions。 ESLint本身等待上游更新后会自动修复。

Optional Chaining 的语法有三种使用场景：

obj?.prop       // optional static property accessobj?.[expr]     // optional dynamic property accessfunc?.(...args) // optional function or method call复制代码

也就是将 . 替换为 ?.，但要注意第二行与第三行稍稍有点反直觉，比如在函数调用时，需要将 func(...args) 写为 func?.(...args)。至于为什么语法不是 func?(...args) 这种简洁一点的表达方式，在 FAQ 中有提到这个例子：

obj?[expr].filter(fun):0 引擎难以判断 obj?[expr] 是 Optional Chaning，亦或这是一个普通的三元运算语句。

可见，要支持 ?. 这个看似简单的语法，在整个 JS 语法体系中要考虑的边界情况很多。

即便是 ?. 这样完整的用法，也需要注意 foo?.3:0 这种情况，不能将 foo?. 解析为 Optional chanining，而要将其解析为 foo? .3 : 0，这需要解析引擎支持 lookahead 特性。

语义

当 ?. 前面的变量值为 null 或 undefined 时，?. 返回的结果为 undefined。

a?.b                          // undefined if `a` is null/undefined, `a.b` otherwise.a == null ? undefined : a.ba?.[x]                        // undefined if `a` is null/undefined, `a[x]` otherwise.a == null ? undefined : a[x]a?.b()                        // undefined if `a` is null/undefineda == null ? undefined : a.b() // throws a TypeError if `a.b` is not a function// otherwise, evaluates to `a.b()`a?.()                        // undefined if `a` is null/undefineda == null ? undefined : a()  // throws a TypeError if `a` is neither null/undefined, nor a function// invokes the function `a` otherwise复制代码

短路

所谓短路，就是指引入了 Optional chaining 后，某些看似一定会执行的语句在特定情况下会短路（终止执行），比如：

a?.[++x]         // `x` is incremented if and only if `a` is not null/undefineda == null ? undefined : a[++x]复制代码

第一个例子，如果 a 时 null/undefined，就不会执行 ++x。

原因是这段代码部分等价于 a == null ? undefined : a[++x]，如果 a == null 为真，自然不会执行 a[++x] 这个语句。但由于 Optional chaining 使这个语句变得 “简洁了”，虽然带来了便利，但也可能导致看不清完整的执行逻辑，引发误判。

所以看到 ?. 语句时，一定要反射性的思考一下，这个语句会触发 “短路”。

长“短路”

Optional chaining 在 JS 的规范中，作用域仅限于调用处。看下面的例子：

a?.b.c(++x).d  // if `a` is null/undefined, evaluates to undefined. Variable `x` is not incremented.// otherwise, evaluates to `a.b.c(++x).d`.a == null ? undefined : a.b.c(++x).d复制代码

可以看到 ?. 仅在 a?. 这一层生效，而不是对后续的 b.c、c(++x).d 继续生效。而对于 C+ 与 CoffeeScript，这个语法是对后续所有 get 生效的（这里再次提醒，不要用 CoffeeScript 了，因为对于相同语法，语义都发生了变化，对你与你的同事都是巨大的理解负担，或者说没有人愿意注意，为什么代码在 CoffeeScript 里不报错，而转移到 JS 就报错了，是因为 Optional chaining 语义不一致造成的。）。

正因为 Optional chaining 在 JS 语法中仅对当前位置起保护作用，因此一个调用语句中允许出现多个 ?. 调用：

a?.b[3].c?.(x).da == null ? undefined : a.b[3].c == null ? undefined : a.b[3].c(x).d// (as always, except that `a` and `a.b[3].c` are evaluated only once)复制代码

上面这段代码，对 a?.b、c?.(x) 的访问与调用是安全的，而对于 b[3]、 b[3].c、c?.(x).d 的调用是不安全的。

在 FAQ 环节也提到了，为什么不学习 C# 与 CoffeeScript 的语义，将安全保护从 a?. 之后就一路 “贯穿” 下去？

原因是 JS 对 Optional chaining 的理解不同导致的。Optional chaining 仅仅是安全访问保护，不代表 try catch，也就是它不会捕获异常，举一个例子：

a?.b()复制代码

这个调用，在 a.b 不是一个函数时依然会报错，原因就是 Optional chaining 仅提供了对属性访问的安全保护，不代表对整个执行过程进行安全保护，该抛出异常还是会抛出异常，因此 Optional chaining 没有必要对后面的属性访问安全性负责。

笔者认为 TC39 对这个属性的理解是合理的，否则用 try catch 就能代替 Optional chaining 了。让一个特性仅实现分内的功能，是每个前端从业者都要具备的思维能力。

PS：笔者再多提一句，在任何技术设计领域，这个概念都适用。想想你设计的功能，写过的函数，如果为了图方便，扩大了其功能，终究会带来整体设计的混乱，适得其反。