前言

在使用ES6新特性的時(shí)候，有時(shí)候會(huì)出現(xiàn)一些奇怪的bug，明明代碼寫得很基礎(chǔ)，一眼就能看懂正在做什么，但是結(jié)果卻往往事與愿違，出現(xiàn)一些完全無法理解的特殊情況，不管是多少次反復(fù)檢查，還是請其他開發(fā)者幫忙檢查，亦或是詢問AI，都無法發(fā)現(xiàn)bug所在，但結(jié)果就是不對，這是為什么呢？

一、問題場景回溯

事情是這樣的：我在實(shí)現(xiàn) RandomizedSet 的時(shí)候，刪除元素時(shí)需要把數(shù)組末尾的值交換到要?jiǎng)h除的位置。邏輯非常清晰，順手就用了解構(gòu)賦值：

RandomizedSet.prototype.remove = function (val) {
    if (this._map.has(val)) {
        let index = this._map.get(val)
        let lastIdx = this._arr.length - 1
        if (index === lastIdx) {
            this._map.delete(val)
            this._arr.pop()
            return true
        }
        let movedVal = this._arr[lastIdx]
        [this._arr[index], this._arr[lastIdx]] = [this._arr[lastIdx], this._arr[index]]
        this._arr.pop()
        this._map.delete(val)
        this._map.set(movedVal, index)
        return true
    }
    return false
};

我很自信這段代碼沒有問題——this._arr 不管是在聲明階段，還是添加和刪除階段，從頭到尾都是數(shù)字?jǐn)?shù)組。但調(diào)試時(shí)卻發(fā)現(xiàn)，movedVal 的某個(gè)元素竟然變成了一個(gè)數(shù)組。

堪稱靈異事件，花費(fèi)很多時(shí)間查找bug都無濟(jì)于事。

二、問題探究

不賣關(guān)子，結(jié)果真相令人哭笑不得：問題出在 let movedVal = this._arr[lastIdx] 后面缺少一個(gè)分號。修改后應(yīng)該是這樣子的：

let movedVal = this._arr[lastIdx];
[this._arr[index], this._arr[lastIdx]] = [this._arr[lastIdx], this._arr[index]]

由于 JavaScript 的自動(dòng)分號插入（ASI）機(jī)制，如果不加分號，上面這段代碼在解析時(shí)會(huì)被認(rèn)為是：

let movedVal = this._arr[lastIdx] [this._arr[index], this._arr[lastIdx]] = [this._arr[lastIdx], this._arr[index]]

也就是說，JS 把 [this._arr[index], this._arr[lastIdx]] 誤認(rèn)為是對 this._arr[lastIdx] 的下標(biāo)訪問，從而整個(gè)邏輯跑偏，movedVal 自然也就莫名其妙地成了數(shù)組。這找誰說理去？

所以推薦在解構(gòu)賦值之前的語句添加分號，這樣就會(huì)可以避免錯(cuò)誤解析了。

三、原理剖析

上文說了，罪魁禍?zhǔn)拙褪?JavaScript 的自動(dòng)分號插入 (ASI)機(jī)制。

JS 解釋器在解析時(shí)，會(huì)嘗試自動(dòng)補(bǔ)充分號，但它有一些固定規(guī)則：行首如果是 [ 或 (，解釋器會(huì)優(yōu)先認(rèn)為它和上一行是同一條語句，所以 [a, b] = ... 被認(rèn)為是上一行的延續(xù)，而不是一條獨(dú)立的解構(gòu)賦值語句。

這個(gè)本質(zhì)上是設(shè)計(jì)不兼容導(dǎo)致的，ASI 在早期 JS 里是“容錯(cuò)機(jī)制”，幫人少打幾個(gè) “ ；” ，但在 ES6 之后，JS 語法更復(fù)雜（解構(gòu)、箭頭函數(shù)、async/await），ASI 就經(jīng)常和直覺沖突。就比如解構(gòu)賦值的 “[” 在 JS 里既可以是表達(dá)式開頭，又可能是語句延續(xù)，這個(gè)時(shí)候 ASI 按照原先的設(shè)計(jì)規(guī)范就會(huì)出岔子。

說透了其實(shí)很簡單，也很好理解，但是不知道的情況下找bug是真的難熬，這種小細(xì)節(jié)問AI，AI完全回答不出來。非得自己發(fā)現(xiàn)才行。

四、拓展：JS 中必須小心分號的場景

說來慚愧，這其實(shí)不是我第一次被 ASI“坑”了。其實(shí)除了解構(gòu)賦值，還有不少典型場景：

1、行首是 [ 或 ( 時(shí)

let arr = [1, 2, 3]
[1, 2, 3].forEach(console.log) // 這里會(huì)出錯(cuò)

//同理，函數(shù)調(diào)用行首是 ( 時(shí)也會(huì)出錯(cuò)：
let fn = function() { console.log("hi") }
(fn)() // ← 如果上面不加分號，這里會(huì)報(bào)錯(cuò)

2、行首是模板字符串（`）

和 '[' 和 '(' 類似，模板字符串如果寫在行首，也會(huì)被拼接到上一行：

let a = "Hello"
`world`.toUpperCase() // 被拼接到上一行

3、return / yield / throw 后換行

這幾個(gè)關(guān)鍵字恰好反過來，不管你加不加分號，后面如果直接換行，JS 會(huì)自動(dòng)插入分號，導(dǎo)致返回值丟失。

function f() {
return
{ x: 1 }
}
console.log(f()) // undefined，而不是 { x: 1 }

4、自增 / 自減運(yùn)算符前置

++ 和 -- 出現(xiàn)在新一行的開頭時(shí)，會(huì)被當(dāng)作上一行的表達(dá)式。

let i = 1
let j = i
++j // 被誤解為 i++

5、解構(gòu)賦值出現(xiàn)在新行（上述場景）

let x = 1
let y = 2
[x, y] = [y, x] // 語法被誤解

6、鏈?zhǔn)秸{(diào)用 / IIFE 立即執(zhí)行函數(shù)

一個(gè)函數(shù)如果前置寫了 “.” ，那么就會(huì)被接到上一行作為鏈?zhǔn)秸{(diào)用，這要是不小心加了一點(diǎn)，檢查的時(shí)候可就費(fèi)勁咯。

// 鏈?zhǔn)秸{(diào)用場景，不小心多寫了個(gè).
let a = b + c
.toString()
// 相當(dāng)于let a = b + c.toString();

// IIFE場景，會(huì)直接報(bào)錯(cuò)
let a = 1
(function() { console.log("IIFE") })()

五、結(jié)語

JavaScript 的 ASI 機(jī)制讓“省略分號”看似優(yōu)雅，但在某些場景下卻暗藏殺機(jī)。尤其是：

• 行首是 [、(、`、+、- 的情況；

• return / throw / yield 后直接換行；

• 解構(gòu)賦值單獨(dú)占一行。

我的建議是：要么保持“全加分號”的風(fēng)格，要么在無分號風(fēng)格下，遇到危險(xiǎn)場景一定要小心換行。不然，像我一樣被 movedVal 莫名其妙變成數(shù)組，還要花半天 debug，可就太冤了。

只有鍛煉思維才能可持續(xù)地解決問題，只有思維才是真正值得學(xué)習(xí)和分享的核心要素。如果這篇博客能給您帶來一點(diǎn)幫助，麻煩您點(diǎn)個(gè)贊支持一下，還可以收藏起來以備不時(shí)之需，有疑問和錯(cuò)誤歡迎在評論區(qū)指出~

到此這篇關(guān)于解構(gòu)賦值的危險(xiǎn)性詳解及js不加分號竟然會(huì)導(dǎo)致報(bào)錯(cuò)解決的文章就介紹到這了,更多相關(guān)js不加分號導(dǎo)致報(bào)錯(cuò)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論