有一個 JavaScript 特性經常被明確禁止使用——eval()函數及其變體。這個看似強大的特性為何會被微軟、谷歌、Facebook等頂級公司列入黑名單？

eval()：強大而危險的雙刃劍

eval()函數可以將字符串作為JavaScript代碼執行，看起來可以實現許多動態功能：

const expr = 'var x = 10; x * 2';
eval(expr); // 返回 20

然而，這種動態執行代碼的能力帶來了嚴重的安全風險和性能問題。

安全隱患：注入攻擊的溫床

最嚴重的問題是安全風險。當eval()與用戶輸入結合時，它成為代碼注入攻擊的完美載體：

攻擊者可以通過這種方式：

• 竊取敏感數據
• 執行惡意操作
• 劫持用戶會話
• 修改頁面內容

性能問題：V8引擎的噩夢

JavaScript引擎無法優化包含eval()的代碼，因為：

• 阻礙編譯優化：使用eval()的函數無法被預編譯
• 禁用內聯緩存：包含eval()的作用域鏈必須保持動態
• 強制變量查找變慢：編譯器無法確定變量引用，必須進行動態解析

Chrome V8團隊的內部測試顯示，含有eval()的代碼執行速度可能慢至少10倍。

可維護性：代碼審計的盲點

使用eval()的代碼：

• 難以調試（堆棧跟蹤不清晰）
• 增加代碼復雜性
• 降低靜態分析工具的有效性
• 使代碼審計變得困難

執行上下文污染

eval()在當前作用域內執行代碼，可能意外修改或覆蓋變量：

大廠的應對策略

Google的JavaScript風格指南明確表示：

“不要使用eval()。它使代碼容易受到注入攻擊，并且使JavaScript引擎難以進行優化。”

微軟的安全編碼準則規定：

“禁止使用eval()和Function構造函數，除非有經過嚴格審核的特殊需求。”

大多數大廠采取的措施包括：

• 嚴格的ESLint規則禁用eval
• 代碼審查中將eval使用標記為嚴重問題
• 提供安全的替代API
• 安全掃描工具自動識別eval的使用

替代方案

對于大多數使用eval()的場景，都存在更好的替代方案：

• 使用JSON.parse替代解析數據

• 使用對象映射替代動態訪問

• 使用新的API替代動態計算

// 不要這樣做
const result = eval('2 * 3 + 4');

// 改用這種方式
const result = new Function('return 2 * 3 + 4')();
// 或更好的方式，使用專門的表達式解析庫