解构赋值的危险性详解及js不加分号竟然会导致报错解决

前言

在使用ES6新特性的时候，有时候会出现一些奇怪的bug，明明代码写得很基础，一眼就能看懂正在做什么，但是结果却往往事与愿违，出现一些完全无法理解的特殊情况，不管是多少次反复检查，还是请其他开发者帮忙检查，亦或是询问AI，都无法发现bug所在，但结果就是不对，这是为什么呢？

一、问题场景回溯

事情是这样的：我在实现 RandomizedSet 的时候，删除元素时需要把数组末尾的值交换到要删除的位置。逻辑非常清晰，顺手就用了解构赋值：

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 不管是在声明阶段，还是添加和删除阶段，从头到尾都是数字数组。但调试时却发现，movedVal 的某个元素竟然变成了一个数组。

堪称灵异事件，花费很多时间查找bug都无济于事。

二、问题探究

不卖关子，结果真相令人哭笑不得：问题出在 let movedVal = this._arr[lastIdx] 后面缺少一个分号。修改后应该是这样子的：

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

由于 JavaScript 的自动分号插入（ASI）机制，如果不加分号，上面这段代码在解析时会被认为是：

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

也就是说，JS 把 [this._arr[index], this._arr[lastIdx]] 误认为是对 this._arr[lastIdx] 的下标访问，从而整个逻辑跑偏，movedVal 自然也就莫名其妙地成了数组。这找谁说理去？

所以推荐在解构赋值之前的语句添加分号，这样就会可以避免错误解析了。

三、原理剖析

上文说了，罪魁祸首就是 JavaScript 的自动分号插入 (ASI)机制。

JS 解释器在解析时，会尝试自动补充分号，但它有一些固定规则：行首如果是 [ 或 (，解释器会优先认为它和上一行是同一条语句，所以 [a, b] = ... 被认为是上一行的延续，而不是一条独立的解构赋值语句。

这个本质上是设计不兼容导致的，ASI 在早期 JS 里是“容错机制”，帮人少打几个 “ ；” ，但在 ES6 之后，JS 语法更复杂（解构、箭头函数、async/await），ASI 就经常和直觉冲突。就比如解构赋值的 “[” 在 JS 里既可以是表达式开头，又可能是语句延续，这个时候 ASI 按照原先的设计规范就会出岔子。

说透了其实很简单，也很好理解，但是不知道的情况下找bug是真的难熬，这种小细节问AI，AI完全回答不出来。非得自己发现才行。

四、拓展：JS 中必须小心分号的场景

说来惭愧，这其实不是我第一次被 ASI“坑”了。其实除了解构赋值，还有不少典型场景：

1、行首是 [ 或 ( 时

let arr = [1, 2, 3]
[1, 2, 3].forEach(console.log) // 这里会出错

//同理，函数调用行首是 ( 时也会出错：
let fn = function() { console.log("hi") }
(fn)() // ← 如果上面不加分号，这里会报错

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

和 '[' 和 '(' 类似，模板字符串如果写在行首，也会被拼接到上一行：

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

3、return / yield / throw 后换行

这几个关键字恰好反过来，不管你加不加分号，后面如果直接换行，JS 会自动插入分号，导致返回值丢失。

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

4、自增 / 自减运算符前置

++ 和 -- 出现在新一行的开头时，会被当作上一行的表达式。

let i = 1
let j = i
++j // 被误解为 i++

5、解构赋值出现在新行（上述场景）

let x = 1
let y = 2
[x, y] = [y, x] // 语法被误解

6、链式调用 / IIFE 立即执行函数

一个函数如果前置写了 “.” ，那么就会被接到上一行作为链式调用，这要是不小心加了一点，检查的时候可就费劲咯。

// 链式调用场景，不小心多写了个.
let a = b + c
.toString()
// 相当于let a = b + c.toString();

// IIFE场景，会直接报错
let a = 1
(function() { console.log("IIFE") })()

五、结语

JavaScript 的 ASI 机制让“省略分号”看似优雅，但在某些场景下却暗藏杀机。尤其是：

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

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

• 解构赋值单独占一行。

我的建议是：要么保持“全加分号”的风格，要么在无分号风格下，遇到危险场景一定要小心换行。不然，像我一样被 movedVal 莫名其妙变成数组，还要花半天 debug，可就太冤了。

只有锻炼思维才能可持续地解决问题，只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助，麻烦您点个赞支持一下，还可以收藏起来以备不时之需，有疑问和错误欢迎在评论区指出~

到此这篇关于解构赋值的危险性详解及js不加分号竟然会导致报错解决的文章就介绍到这了,更多相关js不加分号导致报错内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论