TA貢獻1784條經驗 獲得超2個贊
我想花一點時間來解決你的問題的前提 - eval（）是“ 邪惡的 ”。編程語言人使用的“ 邪惡 ” 一詞通常意味著“危險”，或者更準確地說“能夠通過簡單的命令造成大量傷害”。那么，什么時候可以使用危險的東西呢？當您知道危險是什么時，以及何時采取適當的預防措施。
至關重點，我們來看看使用eval（）的危險性。可能存在許多小的隱患，就像其他一切一樣，但兩個大的風險 - eval（）被認為是邪惡的原因 - 是性能和代碼注入。
性能 - eval（）運行解釋器/編譯器。如果你的代碼是編譯的，那么這是一個很大的問題，因為你需要在運行時調用一個可能很重的編譯器。但是，JavaScript仍然主要是一種解釋語言，這意味著在一般情況下調用eval（）并不是一個很大的性能影響（但請參閱下面的具體說明）。
代碼注入 - eval（）可能在提升的權限下運行一串代碼。例如，以管理員/ root身份運行的程序永遠不會想要eval（）用戶輸入，因為該輸入可能是“rm -rf / etc / important-file”或更糟。同樣，瀏覽器中的JavaScript沒有這個問題，因為程序無論如何都在用戶自己的帳戶中運行。服務器端JavaScript可能存在這個問題。
根據您的具體情況而定。根據我的理解，你自己生成字符串，所以假設你小心不要生成像“rm -rf something-important”這樣的字符串，那么就沒有代碼注入的風險（但請記住，它非常非常在一般情況下很難確保這一點）。此外，如果你在瀏覽器中運行，那么代碼注入是一個非常小的風險，我相信。
至于性能，你將不得不重視編碼的簡易性。我認為，如果你正在解析公式，你也可以在解析期間計算結果，而不是運行另一個解析器（eval（）中的一個）。但是使用eval（）進行編碼可能更容易，并且性能損失可能不明顯?？雌饋韊val（）在這種情況下并不比任何其他可以節省你一些時間的函數更邪惡。
TA貢獻1796條經驗 獲得超7個贊
eval()不是邪惡的。或者，如果是這樣，那就像反射，文件/網絡I / O，線程和IPC在其他語言中是“邪惡的”一樣是邪惡的。
如果出于您的目的，eval()比手動解釋更快，或者使您的代碼更簡單或更清晰......那么您應該使用它。如果不是，那么你不應該。就那么簡單。
TA貢獻1946條經驗 獲得超3個贊
當你信任來源時。
在JSON的情況下，它或多或少難以篡改源，因為它來自您控制的Web服務器。只要JSON本身不包含用戶上傳的數據，使用eval就沒有重大缺陷。
在所有其他情況下，我會竭盡全力確保用戶提供的數據符合我的規則，然后再將其提供給eval（）。
TA貢獻1942條經驗 獲得超3個贊
讓我們真正的人：
現在每個主要的瀏覽器都有一個內置的控制臺，你可能會被黑客大量使用來調用任何有價值的函數 - 為什么他們會費心去使用eval語句 - 即使它們可以？
如果編譯2000行JavaScript需要0.2秒，如果我評估四行JSON，我的性能會下降嗎？
即使是克羅克福德對“eval is evil”的解釋也很薄弱。
eval是Evil，eval函數是JavaScript最被誤用的功能。躲開它
正如克羅克福德本人可能會說的那樣“這種說法往往會產生非理性的神經癥。不要買它?！?/p>
了解eval并了解它何時可能有用更為重要。例如，eval是評估軟件生成的服務器響應的合理工具。
BTW：Prototype.js直接調用eval五次（包括evalJSON（）和evalResponse（））。jQuery在parseJSON中使用它（通過Function構造函數）。
舉報