官方中文版原文链接

感谢社区中各位的大力支持，译者再次奉上一点点福利：阿里云产品券，享受所有官网优惠，并抽取幸运大奖：点击这里领取

我们想要解决的最后一个主要话题是JavaScript的语法如何工作（也称为它的文法）。你可能认为你懂得如何编写JS，但是语言文法的各个部分中有太多微妙的地方导致了困惑和误解，所以我们想要深入这些部分并搞清楚一些事情。

注意： 对于读者们来说，“文法（grammar）”一词不像“语法（syntax）”一词那么为人熟知。在许多意义上，它们是相似的词，描述语言如何工作的 规则。它们有一些微妙的不同，但是大部分对于我们在这里的讨论无关紧要。JavaScript的文法是一种结构化的方式，来描述语法（操作符，关键字，等等）如何组合在一起形成结构良好，合法的程序。换句话说，抛开文法来讨论语法将会忽略许多重要的细节。所以我们在本章中注目的内容的最准确的描述是 文法，尽管语言中的纯语法才是开发者们直接交互的。

语句与表达式

一个很常见的现象是，开发者们假定“语句（statement）”和“表达式（expression）”是大致等价的。但是这里我们需要区分它们俩，因为在我们的JS程序中它们有一些非常重要的区别。

为了描述这种区别，让我们借用一下你可能更熟悉的术语：英语。

一个“句子（sentence）”是一个表达想法的词汇的完整构造。它由一个或多个“短语（phrase）”组成，它们每一个都可以用标点符号或连词（“和”，“或”等等）连接。一个短语本身可以由更小的短语组成。一些短语是不完整的，而且本身没有太多含义，而另一些短语可以自成一句。这些规则总体地称为英语的 文法。

JavaScript文法也类似。语句就是句子，表达式就是短语，而操作符就是连词/标点。

JS中的每一个表达式都可以被求值而成为一个单独的，具体的结果值。举例来说：

var a = 3 * 6;
var b = a;
b;

在这个代码段中，3 * 6是一个表达式（求值得值18）。而第二行的a也是一个表达式，第三行的b也一样。对表达式a和b求值都会得到在那一时刻存储在这些变量中的值，也就偶然是18。

另外，这三行的每一行都是一个包含表达式的语句。var a = 3 * 6和var b = a称为“声明语句（declaration statments）”因为它们每一个都声明了一个变量（并选择性地给它赋值）。赋值a = 3 * 6和b = a（除去var）被称为赋值表达式（assignment expressions）。

第三行仅仅含有一个表达式b，但是它本身也是一个语句（虽然不是非常有趣的一个！）。这一般称为一个“表达式语句（expression statement）”。

语句完成值

一个鲜为人知的事实是，所有语句都有完成值（即使这个值只是undefined）。

你要如何做才能看到一个语句的完成值呢？

最明显的答案是把语句敲进你的浏览器开发者控制台，因为当你运行它时，默认地控制台会报告最近一次执行的语句的完成值。

让我们考虑一下var b = a。这个语句的完成值是什么？

b = a赋值表达式给出的结果是被赋予的值（上面的18），但是var语句本身给出的结果是undefined。为什么？因为在语言规范中var语句就是这么定义的。如果你在你的控制台中敲入var a = 42，你会看到undefined被报告而不是42。

注意： 技术上讲，事情要比这复杂一些。在ES5语言规范，12.2部分的“变量语句”中，VariableDeclaration算法实际上返回了一个值（一个包含被声明变量的名称的string —— 诡异吧！？），但是这个值基本上被VariableStatement算法吞掉了（除了在for..in循环中使用），而这强制产生一个空的（也就是undefined）完成值。

事实上，如果你曾在你的控制台上（或者一个JavaScript环境的REPL —— read/evaluate/print/loop工具）做过很多的代码实验的话，你可能看到过许多不同的语句都报告undefined，而且你也许从来没理解它是什么和为什么。简单地说，控制台仅仅报告语句的完成值。

但是控制台打印出的完成值并不是我们可以在程序中使用的东西。那么我们该如何捕获完成值呢？

这是个更加复杂的任务。在我们解释 如何 之前，让我们先探索一下 为什么 你想这样做。

我们需要考虑其他类型的语句的完成值。例如，任何普通的{ .. }块儿都有一个完成值，即它所包含的最后一个语句/表达式的完成值。

考虑如下代码：

var b;

if (true) {
    b = 4 + 38;
}

如果你将这段代码敲入你的控制台/REPL，你可能会看到它报告42，因为42是if块儿的完成值，它取自if的最后一个复制表达式语句b = 4 + 38。

换句话说，一个块儿的完成值就像 隐含地返回 块儿中最后一个语句的值。

注意： 这在概念上与CoffeeScript这样的语言很类似，它们隐含地从function中return值，这些值与函数中最后一个语句的值是相同的。

但这里有一个明显的问题。这样的代码是不工作的：

var a, b;

a = if (true) {
    b = 4 + 38;
};

我们不能以任何简单的语法/文法来捕获一个语句的完成值并将它赋值给另一个变量（至少是还不能！）。

那么，我们能做什么？

警告： 仅用于演示的目的 —— 不要实际地在你的真实代码中做如下内容！

我们可以使用臭名昭著的eval(..)（有时读成“evil”）函数来捕获这个完成值。

var a, b;

a = eval( "if (true) { b = 4 + 38; }" );

a;  // 42

啊呀呀。这太难看了。但是这好用！而且它展示了语句的完成值是一个真实的东西，不仅仅是在控制台中，还可以在我们的程序中被捕获。

有一个称为“do表达式”的ES7提案。这是它可能工作的方式：

var a, b;

a = do {
    if (true) {
        b = 4 + 38;
    }
};

a;  // 42

do { .. }表达式执行一个块儿（其中有一个或多个语句），这个块儿中的最后一个语句的完成值将成为do表达式的完成值，它可以像展示的那样被赋值给a。

这里的大意是能够将语句作为表达式对待 —— 他们可以出现在其他语句内部 —— 而不必将它们包装在一个内联的函数表达式中，并实施一个明确的return ..。

到目前为止，语句的完成值不过是一些琐碎的事情。不顾随着JS的进化它们的重要性可能会进一步提高，而且很有希望的是do { .. }表达式将会降低使用eval(..)这样的东西的冲动。

警告： 重复我刚才的训诫：避开eval(..)。真的。更多解释参见本系列的 作用域与闭包 一书。

表达式副作用

大多数表达式没有副作用。例如：

var a = 2;
var b = a + 3;

表达式a + 3本身并没有副作用，例如改变a。它有一个结果，就是5，而且这个结果在语句b = a + 3中被赋值给b。

一个最常见的（可能）带有副作用的表达式的例子是函数调用表达式：

function foo() {
    a = a + 1;
}

var a = 1;
foo();      // 结果：`undefined`，副作用：改变 `a`

还有其他的副作用表达式。例如：

var a = 42;
var b = a++;

表达式a++有两个分离的行为。首先，它返回a的当前值，也就是42（然后它被赋值给b）。但 接下来，它改变a本身的值，将它增加1。

var a = 42;
var b = a++;

a;  // 43
b;  // 42

许多开发者错误的认为b和a一样拥有值43。这种困惑源自没有完全考虑++操作符的副作用在 什么时候 发生。

++递增操作符和--递减操作符都是一元操作符（见第四章），它们既可以用于后缀（“后面”）位置也可用于前缀（“前面”）位置。

var a = 42;

a++;    // 42
a;      // 43

++a;    // 44
a;      // 44

当++像++a这样用于前缀位置时，它的副作用（递增a）发生在值从表达式中返回 之前，而不是a++那样发生在 之后。

注意： 你认为++a++是一个合法的语法吗？如果你试一下，你将会得到一个ReferenceError错误，但为什么？因为有副作用的操作符 要求一个变量引用 来作为它们副作用的目标。对于++a++来说，a++这部分会首先被求值（因为操作符优先级 —— 参见下面的讨论），它会给出a在递增 之前 的值。但然后它试着对++42求值，这将（如果你试一下）会给出相同的ReferenceError错误，因为++不能直接在42这样的值上施加副作用。

有时它会被错误地认为，你可以通过将a++包近一个( )中来封装它的 后 副作用，比如：

var a = 42;
var b = (a++);

a;  // 43
b;  // 42

不幸的是，( )本身不会像我们希望的那样，定义一个新的被包装的表达式，而它会在a++表达式的 后副作用 之 后 求值。事实上，就算它能，a++也会首先返回42，而且除非你有另一个表达式在++的副作用之后对a再次求值，你也不会从这个表达式中得到43，于是b不会被赋值为43。

虽然，有另一种选择：,语句序列逗号操作符。这个操作符允许你将多个独立的表达式语句连成一个单独的语句：

var a = 42, b;
b = ( a++, a );

a;  // 43
b;  // 43

注意： a++, a周围的( .. )是必需的。其原因的操作符优先级，我们将在本章后面讨论。

表达式a++, a意味着第二个a语句表达式会在第一个a++语句表达式的 后副作用 之 后 进行求值，这表明它为b的赋值返回43。

另一个副作用操作符的例子是delete。正如我们在第二章中展示的，delete用于从一个object或一个array值槽中移除一个属性。但它经常作为一个独立语句被调用：

var obj = {
    a: 42
};

obj.a;          // 42
delete obj.a;   // true
obj.a;          // undefined

如果被请求的操作是合法/可允许的，delete操作符的结果值为true，否则结果为false。但是这个操作符的副作用是它移除了属性（或数组值槽）。

注意： 我们说合法/可允许是什么意思？不存在的属性，或存在且可配置的属性（见本系列 this与对象原型 的第三章）将会从delete操作符中返回true。否则，其结果将是false或者一个错误。

副作用操作符的最后一个例子，可能既是明显的也是不明显的，是=赋值操作符。

考虑如下代码：

var a;

a = 42;     // 42
a;          // 42

对于这个表达式来说，a = 42中的=看起来似乎不是一个副作用操作符。但如果我们检视语句a = 42的结果值，会发现它就是刚刚被赋予的值（42），所以向a赋予的相同的值实质上是一种副作用。

提示： 相同的原因也适用于+=，-=这样的复合赋值操作符的副作用。例如，a = b += 2被处理为首先进行b += 2（也就是b = b + 2），然后这个赋值的结果被赋予a。

这种赋值表达式（语句）得出被赋予的值的行为，主要在链式赋值上十分有用，就像这样：

var a, b, c;

a = b = c = 42;

这里，c = 42被求值得出42（带有将42赋值给c的副作用），然后b = 42被求值得出42（带有将42赋值给b的副作用），而最后a = 42被求值（带有将42赋值给a的副作用）。

警告： 一个开发者们常犯的错误是将链式赋值写成var a = b = 42这样。虽然这看起来是相同的东西，但它不是。如果这个语句发生在没有另外分离的var b（在作用域的某处）来正式声明它的情况下，那么var a = b = 42将不会直接声明b。根据strict模式的状态，它要么抛出一个错误，要么无意中创建一个全局变量（参见本系列的 作用域与闭包）。

另一个要考虑的场景是：

function vowels(str) {
    var matches;

    if (str) {
        // 找出所有的元音字母
        matches = str.match( /[aeiou]/g );

        if (matches) {
            return matches;
        }
    }
}

vowels( "Hello World" ); // ["e","o","o"]

这可以工作，而且许多开发者喜欢这么做。但是使用一个我们可以利用赋值副作用的惯用法，可以通过将两个if语句组合为一个来进行简化：

function vowels(str) {
    var matches;

    // 找出所有的元音字母
    if (str && (matches = str.match( /[aeiou]/g ))) {
        return matches;
    }
}

vowels( "Hello World" ); // ["e","o","o"]

注意： matches = str.match..周围的( .. )是必需的。其原因是操作符优先级，我们将在本章稍后的“操作符优先级”一节中讨论。

我偏好这种短一些的风格，因为我认为它明白地表示了两个条件其实是有关联的，而非分离的。但是与大多数JS中的风格选择一样，哪一种 更好 纯粹是个人意见。

上下文规则

在JavaScript文法规则中有好几个地方，同样的语法根据它们被使用的地方/方式不同意味着不同的东西。这样的东西可能，孤立的看，导致相当多的困惑。

我们不会在这里详尽地罗列所有这些情况，而只是指出常见的几个。

{ .. } 大括号

在你的代码中一对{ .. }大括号将主要出现在两种地方（随着JS的进化会有更多！）。让我们来看看它们每一种。

对象字面量

首先，作为一个object字面量：

// 假定有一个函数`bar()`的定义

var a = {
    foo: bar()
};

我们怎么知道这是一个object字面量？因为{ .. }是一个被赋予给a的值。

注意： a这个引用被称为一个“l-值”（也称为左手边的值）因为它是赋值的目标。{ .. }是一个“r-值”（也称为右手边的值）因为它仅被作为一个值使用（在这里作为赋值的源）。

标签

如果我们移除上面代码的var a =部分会发生什么？

// 假定有一个函数`bar()`的定义

{
    foo: bar()
}

许多开发者臆测{ .. }只是一个独立的没有被赋值给任何地方的object字面量。但事实上完全不同。

这里，{ .. }只是一个普通的代码块儿。在JavaScript中拥有一个这样的独立{ .. }块儿并不是一个很惯用的形式（在其他语言中要常见得多！），但它是完美合法的JS文法。当与let块儿作用域声明组合使用时非常有用（见本系列的 作用域与闭包）。

这里的{ .. }代码块儿在功能上差不多与附着在一些语句后面的代码块儿是相同的，比如for/while循环，if条件，等等。

但如果它是一个一般代码块儿，那么那个看起来异乎寻常的foo: bar()语法是什么？它怎么会是合法的呢？

这是因为一个鲜为人知的（而且，坦白地说，不鼓励使用的）称为“打标签的语句”的JavaScript特性。foo是语句bar()（这个语句省略了末尾的;—— 见本章稍后的“自动分号”）的标签。但一个打了标签的语句有何意义？

如果JavaScript有一个goto语句，那么在理论上你就可以说goto foo并使程序的执行跳转到代码中的那个位置。goto通常被认为是一种糟糕的编码惯用形式，因为它们使代码更难于理解（也称为“面条代码”），所以JavaScript没有一般的goto语句是一件 非常好的事情。

然而，JS的确支持一种有限的，特殊形式的goto：标签跳转。continue和break语句都可以选择性地接受一个指定的标签，在这种情况下程序流会有些像goto一样“跳转”。考虑一下代码：

// 用`foo`标记的循环
foo: for (var i=0; i<4; i++) {
    for (var j=0; j<4; j++) {
        // 每当循环相遇，就继续外层循环
        if (j == i) {
            // 跳到被`foo`标记的循环的下一次迭代
            continue foo;
        }

        // 跳过奇数的乘积
        if ((j * i) % 2 == 1) {
            // 内层循环的普通（没有被标记的） `continue`
            continue;
        }

        console.log( i, j );
    }
}
// 1 0
// 2 0
// 2 1
// 3 0
// 3 2

注意： continue foo不意味着“走到标记为‘foo’的位置并继续”，而是，“继续标记为‘foo’的循环，并进行下一次迭代”。所以，它不是一个 真正的 随意的goto。

如你所见，我们跳过了乘积为奇数的3 1迭代，而且被打了标签的循环跳转还跳过了1 1和2 2的迭代。

也许标签跳转的一个稍稍更有用的形式是，使用break __从一个内部循环里面跳出外部循环。没有带标签的break，同样的逻辑有时写起来非常尴尬：

// 用`foo`标记的循环
foo: for (var i=0; i<4; i++) {
    for (var j=0; j<4; j++) {
        if ((i * j) >= 3) {
            console.log( "stopping!", i, j );
            // 跳出被`foo`标记的循环
            break foo;
        }

        console.log( i, j );
    }
}
// 0 0
// 0 1
// 0 2
// 0 3
// 1 0
// 1 1
// 1 2
// stopping! 1 3

注意： break foo不意味着“走到‘foo’标记的位置并继续”，而是，“跳出标记为‘foo’的循环/代码块儿，并继续它 后面 的部分”。不是一个传统意义上的goto，对吧？

对于上面的问题，使用不带标签的break将可能会牵连一个或多个函数，共享作用域中变量的访问，等等。它很可能要比带标签的break更令人糊涂，所以在这里使用带标签的break也许是更好的选择。

一个标签也可以用于一个非循环的块儿，但只有break可以引用这样的非循环标签。你可以使用带标签的break ___跳出任何被标记的块儿，但你不能continue ___一个非循环标签，也不能用一个不带标签的break跳出一个块儿。

function foo() {
    // 用`bar`标记的块儿
    bar: {
        console.log( "Hello" );
        break bar;
        console.log( "never runs" );
    }
    console.log( "World" );
}

foo();
// Hello
// World

带标签的循环/块儿极不常见，而且经常使人皱眉头。最好尽可能地避开它们；比如使用函数调用取代循环跳转。但是也许在一些有限的情况下它们会有用。如果你打算使用标签跳转，那么就确保使用大量注释在文档中记下你在做什么！

一个很常见的想法是，JSON是一个JS的恰当子集，所以一个JSON字符串（比如{"a":42} —— 注意属性名周围的引号是JSON必需的！）被认为是一个合法的JavaScript程序。不是这样的！ 如果你试着把{"a":42}敲进你的JS控制台，你会得到一个错误。

这是因为语句标签周围不能有引号，所以"a"不是一个合法的标签，因此:不能出现在它后面。

所以，JSON确实是JS语法的子集，但是JSON本身不是合法的JS文法。

按照这个路线产生的一个极其常见的误解是，如果你将一个JS文件加载进一个<script src=..>标签，而它里面仅含有JSON内容的话（就像从API调用中得到那样），这些数据将作为合法的JavaScript被读取，但只是不能从程序中访问。JSON-P（将JSON数据包进一个函数调用的做法，比如foo({"a":42})）经常被说成是解决了这种不可访问性，通过向你程序中的一个函数发送这些值。

不是这样的！ 实际上完全合法的JSON值{"a":42}本身将会抛出一个JS错误，因为它被翻译为一个带有非法标签的语句块儿。但是foo({"a":42})是一个合法的JS，因为在它里面，{"a":42}是一个被传入foo(..)的object字面量值。所以，更合适的说法是，JSON-P使JSON成为合法的JS文法！

块儿

另一个常为人所诟病的JS坑（与强制转换有关 —— 见第四章）是：

[] + {}; // "[object Object]"
{} + []; // 0

这看起来暗示着+操作符会根据第一个操作数是[]还是{}而给出不同的结果。但实际上这与它一点儿关系都没有！

在第一行中，{}出现在+操作符的表达式中，因此被翻译为一个实际的值（一个空object）。第四章解释过，[]被强制转换为""因此{}也会被强制转换为一个string："[object Object]"。

但在第二行中，{}被翻译为一个独立的{}空代码块儿（它什么也不做）。块儿不需要分号来终结它们，所以这里缺少分号不是一个问题。最终，+ []是一个将[]明确强制转换 为number的表达式，而它的值是0。

对象解构

从ES6开始，你将看到{ .. }出现的另一个地方是“解构赋值”（更多信息参见本系列的 ES6与未来），确切地说是object解构。考虑下面的代码：

function getData() {
    // ..
    return {
        a: 42,
        b: "foo"
    };
}

var { a, b } = getData();

console.log( a, b ); // 42 "foo"

正如你可能看出来的，var { a , b } = ..是ES6解构赋值的一种形式，它大体等价于：

var res = getData();
var a = res.a;
var b = res.b;

注意： { a, b } 实际上是{ a: a, b: b }的ES6解构缩写，两者都能工作，但是人们期望短一些的{ a, b }能成为首选的形式。

使用一个{ .. }进行对象解构也可用于被命名的函数参数，这时它是同种类的隐含对象属性赋值的语法糖：

function foo({ a, b, c }) {
    // 不再需要：
    // var a = obj.a, b = obj.b, c = obj.c
    console.log( a, b, c );
}

foo( {
    c: [1,2,3],
    a: 42,
    b: "foo"
} );    // 42 "foo" [1, 2, 3]

所以，我们使用{ .. }的上下文环境整体上决定了它们的含义，这展示了语法和文法之间的区别。理解这些微妙之处以回避JS引擎进行意外的翻译是很重要的。

else if 和可选块儿

一个常见的误解是JavaScript拥有一个else if子句，因为你可以这么做：

if (a) {
    // ..
}
else if (b) {
    // ..
}
else {
    // ..
}

但是这里有一个JS文法隐藏的性质：它没有else if。但是如果附着在if和else语句后面的代码块儿仅包含一个语句时，if和else语句允许省略这些代码块儿周围的{ }。毫无疑问，你以前已经见过这种现象很多次了：

if (a) doSomething( a );

许多JS编码风格指引坚持认为，你应当总是在一个单独的语句块儿周围使用{ }，就像：

if (a) { doSomething( a ); }

然而，完全相同的文法规则也适用于else子句，所以你经常编写的else if形式 实际上 被解析为：

if (a) {
    // ..
}
else {
    if (b) {
        // ..
    }
    else {
        // ..
    }
}

if (b) { .. } else { .. }是一个紧随着else的单独的语句，所以你在它周围放不放一个{ }都可以。换句话说，当你使用else if的时候，从技术上讲你就打破了那个常见的编码风格指导的规则，而且只是用一个单独的if语句定义了你的else。

当然，else if惯用法极其常见，而且减少了一级缩进，所以它很吸引人。无论你用哪种方式，就在你自己的编码风格指导/规则中明确地指出它，并且不要臆测else if是直接的文法规则。

操作符优先级

就像我们在第四章中讲解的，JavaScript版本的&&和||很有趣，因为它们选择并返回它们的操作数之一，而不是仅仅得出true或false的结果。如果只有两个操作数和一个操作符，这很容易推理。

var a = 42;
var b = "foo";

a && b; // "foo"
a || b; // 42

但是如果牵扯到两个操作符，和三个操作数呢？

var a = 42;
var b = "foo";
var c = [1,2,3];

a && b || c; // ???
a || b && c; // ???

要明白这些表达式产生什么结果，我们就需要理解当在一个表达式中有多于一个操作符时，什么样的规则统治着操作符被处理的方式。

这些规则称为“操作符优先级”。

我打赌大多数读者都觉得自己已经很好地理解了操作符优先级。但是和我们在本系列丛书中讲解的其他一切东西一样，我们将拨弄这种理解来看看它到底有多扎实，并希望能在这个过程中学到一些新东西。

回想上面的例子：

var a = 42, b;
b = ( a++, a );

a;  // 43
b;  // 43

要是我们移除了( )会怎样？

var a = 42, b;
b = a++, a;

a;  // 43
b;  // 42

等一下！为什么这改变了赋给b的值？

因为,操作符要比=操作符的优先级低。所以，b = a++, a被翻译为(b = a++), a。因为（如我们前面讲解的）a++拥有 后副作用，赋值给b的值就是在++改变a之前的值42。

这只是为了理解操作符优先级所需的一个简单事实。如果你将要把,作为一个语句序列操作符使用，那么知道它实际上拥有最低的优先级是很重要的。任何其他的操作符都将要比,结合得更紧密。

现在，回想上面的这个例子：

if (str && (matches = str.match( /[aeiou]/g ))) {
    // ..
}

我们说过赋值语句周围的( )是必须的，但为什么？因为&&拥有的优先级比=更高，所以如果没有( )来强制结合，这个表达式将被作为(str && matches) = str.match..对待。但是这将是个错误，因为(str && matches)的结果将不是一个变量（在这里是undefined），而是一个值，因此它不能成为=赋值的左边！

好了，那么你可能认为你已经搞定操作符优先级了。

让我们移动到更复杂的例子（在本章下面几节中我们将一直使用这个例子），来 真正 测试一下你的理解：

var a = 42;
var b = "foo";
var c = false;

var d = a && b || c ? c || b ? a : c && b : a;

d;      // ??

好的，邪恶，我承认。没有人会写这样的表达式串，对吧？也许 不会，但是我们将使用它来检视将多个操作符链接在一起时的各种问题，而链接多个操作符是一个非常常见的任务。

上面的结果是42。但是这根本没意思，除非我们自己能搞清楚这个答案，而不是将它插进JS程序来让JavaScript搞定它。

让我们深入挖掘一下。

第一个问题 —— 你可能还从来没问过 —— 是，第一个部分（a && b || c）是像(a && b) || c那样动作，还是像a && (b || c)那样动作？你能确定吗？你能说服你自己它们实际上是不同的吗？

(false && true) || true;    // true
false && (true || true);    // false

那么，这就是它们不同的证据。但是false && true || true到底是如何动作的？答案是：

false && true || true;      // true
(false && true) || true;    // true

那么我们有了答案。&&操作符首先被求值，而||操作符第二被求值。

但这不是因为从左到右的处理顺序吗？让我们把操作符的顺序倒过来：

true || false && false;     // true

(true || false) && false;   // false -- 不
true || (false && false);   // true -- 这才是胜利者!

现在我们证明了&&首先被求值，然后才是||，而且在这个例子中的顺序实际上是与一般希望的从左到右的顺序相反的。

那么什么导致了这种行为？操作符优先级。

每种语言都定义了自己的操作符优先级列表。虽然令人焦虑，但是JS开发者读过JS的列表却不太常见。

如果你熟知它，上面的例子一点儿都不会绊到你，因为你已经知道了&&要比||优先级高。但是我打赌有相当一部分读者不得不将它考虑一会。

注意： 不幸的是，JS语言规范没有将它的操作符优先级罗列在一个方便，单独的位置。你不得不通读并理解所有的文法规则。所以我们将试着以一种更方便的格式排列出更常见和更有用的部分。要得到完整的操作符优先级列表，参见MDN网站的“操作符优先级”(* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence)。

短接

在第四章中，我们在一个边注中提到了操作符&&和||的“短接”性质。让我们更详细地重温它们。

对于&&和||两个操作符来说，如果左手边的操作数足够确定操作的结果，那么右手边的操作数将 不会被求值。故而，有了“短接”（如果可能，它就会取捷径退出）这个名字。

例如，说a && b，如果a是falsyb就不会被求值，因为&&操作数的结果已经确定了，所以再去麻烦地检查b是没有意义的。同样的，说a || b，如果a是truthy，那么操作的结果就已经确定了，所以没有理由再去检查b。

这种短接非常有帮助，而且经常被使用：

function doSomething(opts) {
    if (opts && opts.cool) {
        // ..
    }
}

opts && opts.cool测试的opts部分就像某种保护，因为如果opts没有被赋值（或不是一个object），那么表达式opts.cool就将抛出一个错误。opts测试失败加上短接意味着opts.cool根本不会被求值，因此没有错误！

相似地，你可以用||短接：

function doSomething(opts) {
    if (opts.cache || primeCache()) {
        // ..
    }
}

这里，我们首先检查opts.cache，如果它存在，我们就不会调用primeCache()函数，如此避免了潜在的不必要的工作。

更紧密的绑定

让我们把注意力转回前面全是链接的操作符的复杂语句的例子，特别是? :三元操作符的部分。? :操作对的优先级与&&和||操作符比起来是高还是低？

a && b || c ? c || b ? a : c && b : a

它是更像这样：

a && b || (c ? c || (b ? a : c) && b : a)

还是这样？

(a && b || c) ? (c || b) ? a : (c && b) : a

答案是第二个。但为什么？

因为&&优先级比||高，而||优先级比? :高。

所以，表达式(a && b || c)在? :参与之前被 首先 求值。另一种常见的解释方式是，&&和||要比? :“结合的更紧密”。如果倒过来成立的话，那么c ? c..将结合的更紧密，那么它就会如a && b || (c ? c..)那样动作（就像第一种选择）。

结合性

所以，&&和||操作符首先集合，然后是? :操作符。但是多个同等优先级的操作符呢？它们总是从左到右或是从右到左地处理吗？

一般来说，操作符不是左结合的就是右结合的，这要看 分组是从左边发生还是从右边发生。

至关重要的是，结合性与从左到右或从右到左的处理 不是 同一个东西。

但为什么处理是从左到右或从右到左那么重要？因为表达式可以有副作用，例如函数调用：

var a = foo() && bar();

这里，foo()首先被求值，然后根据表达式foo()的结果，bar()可能会求值。如果bar()在foo()之前被调用绝对会得出不同的程序行为。

但是这个行为就是从左到右的处理（JavaScript中的默认行为！）—— 它与&&的结合性无关。在这个例子中，因为这里只有一个&&因此没有相关的分组，所以根本谈不上结合性。

但是像a && b && c这样的表达式，分组将会隐含地发生，意味着不是a && b就是b && c会先被求值。

技术上讲，a && b && c将会作为(a && b) && c处理，因为&&是左结合的（顺带一提，||也是）。然而，右结合的a && (b && c)也表现出相同的行为。对于相同的值，相同的表达式是按照相同的顺序求值的。

注意： 如果假设&&是右结合的，它就会与你手动使用( )建立a && (b && c)这样的分组的处理方式一样。但是这仍然 不意味着 c将会在b之前被处理。右结合性的意思 不是 从右到左求值，它的意思是从右到左 分组。不管哪种方式，无论分组/结合性怎样，严格的求值顺序将是a，然后b，然后c（也就是从左到右）。

因此，除了使我们对它们定义的讨论更准确以外，&&和||是左结合这件事没有那么重要。

但事情不总是这样。一些操作符根据左结合性与右结合性将会做出不同的行为。

考虑? :（“三元”或“条件”）操作符：

a ? b : c ? d : e;

? :是右结合的，那么哪种分组表现了它将被处理的方式？

• a ? b : (c ? d : e)
• (a ? b : c) ? d : e

答案是a ? b : (c ? d : e)。不像上面的&&和||，在这里右结合性很重要，因为对于一些（不是全部！）值的组合来说(a ? b : c) ? d : e的行为将会不同。

一个这样的例子是：

true ? false : true ? true : true;      // false

true ? false : (true ? true : true);    // false
(true ? false : true) ? true : true;    // true

在其他的值的组合中潜伏着更加微妙的不同，即便他们的最终结果是相同的。考虑：

true ? false : true ? true : false;     // false

true ? false : (true ? true : false);   // false
(true ? false : true) ? true : false;   // false

在这个场景中，相同的最终结果暗示着分组是没有实际意义的。然而：

var a = true, b = false, c = true, d = true, e = false;

a ? b : (c ? d : e); // false, 仅仅对 `a` 和 `b` 求值
(a ? b : c) ? d : e; // false, 对 `a`, `b` 和 `e` 求值

这样，我们就清楚地证明了? :是右结合的，而且在这个操作符与它自己链接的方式上，右结合性是发挥影响的。

另一个右结合（分组）的例子是=操作符。回想本章早先的链式赋值的例子：

var a, b, c;

a = b = c = 42;

我们早先断言过，a = b = c = 42的处理方式是，首先对c = 42赋值求值，然后是b = ..，最后是a = ..。为什么？因为右结合性，它实际上这样看待这个语句：a = (b = (c = 42))。

记得本章前面，我们的复杂赋值表达式的实例吗？

var a = 42;
var b = "foo";
var c = false;

var d = a && b || c ? c || b ? a : c && b : a;

d;      // 42

随着我们使用优先级和结合性的知识把自己武装起来，我们应当可以像这样把这段代码分解为它的分组行为：

((a && b) || c) ? ((c || b) ? a : (c && b)) : a

或者，如果这样容易理解的话，可以用缩进表达：

(
  (a && b)
    ||
  c
)
  ?
(
  (c || b)
    ?
  a
    :
  (c && b)
)
  :
a

让我们解析它：

1. (a && b)是"foo".
2. "foo" || c是"foo".
3. 对于第一个?测试，"foo"是truthy。
4. (c || b)是"foo".
5. 对于第二个?测试, "foo"是truthy。
6. a是42.

就是这样，我们搞定了！答案是42，正如我们早先看到的。其实它没那么难，不是吗？

消除歧义

现在你应该对操作符优先级（和结合性）有了更好的把握，并对理解多个链接的操作符如何动作感到更适应了。

但还存在一个重要的问题：我们应当一直编写完美地依赖于操作符优先级/结合性的代码吗？我们应该仅在有必要强制一种不同的处理顺序时使用( )手动分组吗？

或者，另一方面，我们应当这样认识吗：虽然这样的规则 实际上 是可以学懂的，但是太多的坑让我们不得不忽略自动优先级/结合性？如果是这样，我们应当总是使用( )手动分组并移除对这些自动行为的所有依赖吗？

这种争论是非常主观的，而且和第四章中关于 隐含 强制转换的争论是强烈对称的。大多数开发者对这两个争论的感觉是一样的：要么他们同时接受这两种行为并使用它们编码，要么他们同时摒弃两种行为并坚持手动/明确的写法。

当然，在这个问题上，我们不能给出比我在第四章中给出的更绝对的答案。但我向你展示了利弊，并且希望促进了你更深刻的理解，以使你可以做出合理而不是人云亦云的决定。

在我看来，这里有一个重要的中间立场。我们应当将操作符优先级/结合性 与 ( )手动分组两者混合进我们的程序 —— 我在第四章中对于 隐含的 强制转换的健康/安全用法做过同样的辩论，但当然不会没有界限地仅仅拥护它。

例如，对我来说if (a && b && c) ..是完全没问题的，而我不会为了明确表现结合性而写出if ((a && b) && c) ..，因为我认为这过于繁冗了。

另一方面，如果我需要链接两个? :条件操作符，我会理所当然地使用( )手动分组来使我意图的逻辑表达的绝对清晰。

因此，我在这里的意见和在第四章中的相似：在操作符优先级/结合性可以使代码更短更干净的地方使用操作符优先级/结合性，在( )手动分组可以帮你创建更清晰的代码并减少困惑的地方使用( )手动分组