JavaScript中的普通函數和箭頭函數

最近被問到了一個問題：

javaScript 中的箭頭函數 ( => ) 和普通函數 ( function ) 有什么區別？

我當時想的就是：這個問題很簡單啊~（flag），然后做出了錯誤的回答……

箭頭函數中的 this 和調用時的上下文無關，而是取決於定義時的上下文

這並不是很正確的答案……雖然也不是完全錯誤

箭頭函數中的 this

首先說我的回答中沒有錯誤的部分：箭頭函數中的 this 確實和調用時的上下文無關

function make () {
    return ()=>{
        console.log(this);
    }
}

const testFunc = make.call({ name:'foo' });

testFunc(); //=> { name:'foo' }
testFunc.call({ name:'bar' }); //=> { name:'foo' }

這個例子可以看到，確實箭頭函數在定義之后，this 就不會發生改變了，無論用什么樣的方式調用它，this 都不會改變；
但嚴格來說，這並不是“取決於定義時的上下文”， 因為箭頭函數根本就沒有綁定自己的 this，在箭頭函數中調用 this 時，僅僅是簡單的沿着作用域鏈向上尋找，找到最近的一個 this 拿來使用罷了；
從效果上看，這和我之前的理解並沒有多大偏差，但它們的本質卻是截然不同，箭頭函數並不是普通函數新增了 this 不受調用時上下文影響的特性，而是減少了很多特性；

箭頭函數其實是更簡單的函數

實際上箭頭函數中並不只是 this 和普通函數有所不同，箭頭函數中沒有任何像 this 這樣自動綁定的局部變量，包括：this，arguments，super(ES6)，new.target(ES6)……
借用別人的一個例子：

function foo() {
   setTimeout( () => {
      console.log("args:", arguments);
   },100);
}

foo( 2, 4, 6, 8 );
// args: [2, 4, 6, 8]

在普通函數中，會自動綁定上的各種局部變量，箭頭函數都是十分單純的沿着作用域鏈向上尋找……
箭頭函數就是這么個簡單、純粹的東西；
所以我個人認為箭頭函數更適合函數式編程，除了它更短以外，使用箭頭函數也更難被那些沒有顯示聲明的變量影響，導致你產生意料之外的計算結果；

那么普通函數能否實現和箭頭函數一樣的效果呢？

如果是像當初的我一樣簡單的考慮固定住 this 這個易變的家伙……那倒是很簡單，有些常用的方法，比如這樣：

function make () {
    var self = this;
    return function () {
        console.log(self);
    }
}

或者

function make () {
    return function () {
        console.log(this);
    }.bind(this);
}

然而第二種方法只能固定 this 這一個變量而已，如前文所述，箭頭函數中的 arguments 等變量也是從作用域鏈中尋找的，為了實現類似的效果，我們只有重新定義一個局部變量這一種方式，而 babel 也是使用這種方式對箭頭函數進行處理的。

function make () {
    return ()=>{
        console.log(this);
        console.log(arguments);
    }
}

//babel it...

function make() {
    var _this = this,
        _arguments = arguments;

    return function () {
        console.log(_this);
        console.log(_arguments);
    };
}

那么……如果我想在箭頭函數中使用 arguments 該怎么辦？

……我覺得如果你有這個需求，可能還是用普通函數更合適一點……
但並不是說在箭頭函數中無法以類似數組的形式取到所有參數，我們可以利用展開運算符來接收參數，比如這樣：

const testFunc = (...args)=>{
    console.log(args) //數組形式輸出參數
}

或許真的有場景需要用到這種寫法，但我還是認為，箭頭函數更適合那些接受固定的參數，返回一個計算結果的簡單情況；

特別感謝 vajoy 所譯 getify 大神的文章，把我從錯誤的理解上引導回來；
同時也讓我明白了，有些時候代碼運行的結果和你的預期相同，未必就代表代碼運行的原理和你的理解相同

如果這篇文章中有什么錯誤或不足，歡迎指正