作者：王欣彤
鏈接：http://www.zhihu.com/question/20591877/answer/57705130
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
鏈接：http://www.zhihu.com/question/20591877/answer/57705130
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
不推薦使用eval的原因有很多，
1、eval 太神秘了，以至於很多人用錯。所以不推薦使用。
比如這段代碼你應該見過：
然而實際上，我們可以這樣寫：
這並不是eval 不好而是因為容易被用錯。
eval只是一個普通的函數，只不過他有一個快速通道通向編譯器，可以將string變成可執行的代碼。有類似功能的還有Function , setInterval 和 setTimeout。
2、 eval不容易調試。用chromeDev等調試工具無法打斷點調試，所以麻煩的東西也是不推薦使用的…
3、說到性能問題，在舊的瀏覽器中如果你使用了eval，性能會下降10倍。在現代瀏覽器中有兩種編譯模式：fast path和slow path。fast path是編譯那些穩定和可預測（stable and predictable）的代碼。而明顯的，eval不可預測，所以將會使用slow path ，所以會慢。
還有一個是，在使用類似於Closure Compiler等壓縮（混淆）代碼時，使用eval會報錯。
（又慢又報錯，我還推薦嗎？）
4、關於安全性，我們經常聽到eval是魔鬼，他會引起XSS攻擊，實際上，如果我們對信息源有足夠的把握時，eval並不會引起很大的安全問題。而且不光是eval，其他方式也可能引起安全問題。比如：
莫名其妙給你注入一個<script src="">標簽，或者一段來歷不明的JSON-P請求，再或者就是Ajax請求中的eval代碼…
1、eval 太神秘了，以至於很多人用錯。所以不推薦使用。
比如這段代碼你應該見過：
然而實際上，我們可以這樣寫：
這並不是eval 不好而是因為容易被用錯。
eval只是一個普通的函數，只不過他有一個快速通道通向編譯器，可以將string變成可執行的代碼。有類似功能的還有Function , setInterval 和 setTimeout。
2、 eval不容易調試。用chromeDev等調試工具無法打斷點調試，所以麻煩的東西也是不推薦使用的…
3、說到性能問題，在舊的瀏覽器中如果你使用了eval，性能會下降10倍。在現代瀏覽器中有兩種編譯模式：fast path和slow path。fast path是編譯那些穩定和可預測（stable and predictable）的代碼。而明顯的，eval不可預測，所以將會使用slow path ，所以會慢。
還有一個是，在使用類似於Closure Compiler等壓縮（混淆）代碼時，使用eval會報錯。
（又慢又報錯，我還推薦嗎？）
4、關於安全性，我們經常聽到eval是魔鬼，他會引起XSS攻擊，實際上，如果我們對信息源有足夠的把握時，eval並不會引起很大的安全問題。而且不光是eval，其他方式也可能引起安全問題。比如：
莫名其妙給你注入一個<script src="">標簽，或者一段來歷不明的JSON-P請求，再或者就是Ajax請求中的eval代碼…
所以啊，只要你的信息源不安全，你的代碼就不安全。不單單是因為eval引起的。
你用eval的時候會在意XSS的問題，你越在意就越出問題，出的多了，eval就成噩夢了。
5、效率問題是程序邏輯問題。對於一些有執行字符串代碼需求的程序中，不用eval而用其他方式模擬反而會帶來更大的開銷。
你用eval的時候會在意XSS的問題，你越在意就越出問題，出的多了，eval就成噩夢了。
5、效率問題是程序邏輯問題。對於一些有執行字符串代碼需求的程序中，不用eval而用其他方式模擬反而會帶來更大的開銷。
作者：王欣彤
鏈接：http://www.zhihu.com/question/20591877/answer/57705130
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
http://www.zhihu.com/question/20591877