JavaScript 中十個“過時”的 API，你的代碼里還在用嗎？
JavaScript 作為一門不斷發展的語言，其API也在持續進化。新的、更安全、更高效的API不斷涌現，而一些舊的API則因為各種原因（如安全問題、性能瓶頸、設計缺陷或有了更好的替代品）被標記為“廢棄”（Deprecated）。繼續使用這些廢棄的API可能會導致兼容性問題、安全漏洞，或者讓我們的代碼難以維護。
1. document.execCommand()
為什么廢棄/不推薦：document.execCommand() 曾是實現富文本編輯（如加粗、斜體、復制、粘貼）的主要方式。然而，它的行為在不同瀏覽器之間存在顯著差異，API本身也難以擴展和維護。更重要的是，它存在潛在的安全風險（例如，不當使用可能導致XSS攻擊）。W3C已明確表示不再推薦使用此API，并鼓勵開發者轉向更現代的解決方案。
替代方案：
- Clipboard API (navigator.clipboard): 用于異步復制和粘貼文本或數據，更安全、更現代。
- Selection API: 用于獲取和修改用戶當前選中的文本或范圍。
- 直接操作DOM: 對于富文本編輯，許多現代編輯器庫（如Quill, Slate.js, Draft.js）或自定義邏輯會直接操作DOM來實現所需效果。
// 不推薦
// document.execCommand('copy');
// 推薦 (復制文本)
async function copyTextToClipboard(text) {
try {
await navigator.clipboard.writeText(text);
console.log('Text copied to clipboard');
} catch (err) {
console.error('Failed to copy: ', err);
}
}2. escape() 和 unescape()
為什么廢棄：這兩個函數用于URL編碼和解碼，但它們存在嚴重缺陷：
- 它們不會正確處理非ASCII字符（如中文）。
- 它們不會對所有在URL中具有特殊意義的字符進行編碼（例如 +, /, @）。
替代方案：
- encodeURIComponent() / decodeURIComponent(): 用于編碼和解碼URL的查詢字符串參數部分。這是最常用的，因為它會對所有必要的字符進行編碼。
- encodeURI() / decodeURI(): 用于編碼和解碼整個URI。它們不會對一些URI中合法的特殊字符（如 :, /, ;, ?）進行編碼。
// 不推薦
// const encoded = escape("你好 world?query=1");
// console.log(encoded); // %u4F60%u597D%20world%3Fquery%3D1 (非ASCII字符處理不當)
// 推薦
const queryParam = "你好 world";
const encodedParam = encodeURIComponent(queryParam);
console.log(encodedParam); // %E4%BD%A0%E5%A5%BD%20world
const fullUrl = `https://example.com/search?q=${encodedParam}`;
console.log(fullUrl); // https://example.com/search?q=%E4%BD%A0%E5%A5%BD%20world3. 同步的 XMLHttpRequest
為什么不推薦：在 XMLHttpRequest 的 open() 方法中將第三個參數（async）設置為 false 會發起一個同步請求。這會阻塞JavaScript主線程，直到請求完成，導致瀏覽器界面凍結，用戶體驗極差。現代Web開發強烈推薦使用異步操作。
替代方案：
- 異步 XMLHttpRequest: 默認行為，使用回調函數或Promise處理響應。
- fetch API: 更現代、基于Promise的API，提供了更簡潔和強大的網絡請求方式。
// 極不推薦
// const xhr = new XMLHttpRequest();
// xhr.open('GET', '/api/data', false); // false 表示同步
// xhr.send();
// if (xhr.status === 200) {
// console.log(xhr.responseText); // 阻塞直到響應
// }
// 推薦 (使用 fetch)
async function fetchData(url) {
try {
const response = await fetch(url);
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json(); // 或 .text() 等
console.log(data);
} catch (error) {
console.error('Fetch error:', error);
}
}
fetchData('/api/data');4. String.prototype.substr()
為什么廢棄：substr() 方法從一個指定的起始位置提取指定長度的子字符串。它已被ECMAScript標準標記為“legacy feature”（遺留特性），主要是因為其第二個參數（子串長度）與其他字符串提取方法（如 substring 和 slice，它們的第二個參數是結束索引）不一致，容易造成混淆。
替代方案：
- String.prototype.substring(indexStart, indexEnd): 提取 indexStart 到 indexEnd（不包括）之間的字符。
- String.prototype.slice(beginIndex, endIndex): 與 substring 類似，但可以接受負數索引（表示從字符串末尾開始計數）。
5. Event.keyCode, Event.which, Event.charCode
為什么廢棄：這些屬性用于獲取鍵盤事件中按下的鍵。然而，它們的值在不同瀏覽器、不同操作系統甚至不同鍵盤布局下都可能不一致，導致兼容性問題和開發困擾。
替代方案：
- Event.key: 返回一個表示按鍵物理值的字符串（例如 "a", "Enter", "ArrowUp"）。這是最推薦的方式，因為它更直觀且具有更好的國際化支持。
- Event.code: 返回一個表示物理按鍵代碼的字符串（例如 "KeyA", "Enter", "ArrowUp"），不受鍵盤布局影響。
6. window.event (全局事件對象)
為什么不推薦：在舊的IE瀏覽器事件模型中，事件對象是通過全局的 window.event 訪問的。現代瀏覽器遵循W3C標準，將事件對象作為第一個參數傳遞給事件處理函數。依賴全局 window.event 會導致代碼在非IE舊版瀏覽器或嚴格模式下失效。
替代方案：使用傳遞給事件處理函數的事件對象
7. String.prototype.trimLeft() 和 String.prototype.trimRight()
為什么廢棄：這兩個方法用于移除字符串開頭或結尾的空白字符。它們已被ECMAScript標準采納，但名稱更改為 trimStart() 和 trimEnd() 以獲得更好的語義一致性（與 padStart() 和 padEnd() 等方法對齊）。雖然舊名稱在很多瀏覽器中仍可作為別名使用，但推薦使用標準名稱。
替代方案：
- String.prototype.trimStart()
- String.prototype.trimEnd()
8. Window.showModalDialog()
為什么廢棄：showModalDialog() 用于打開一個模態對話框，它會阻塞父窗口的JavaScript執行，直到對話框關閉。這種阻塞行為與現代Web應用的異步、非阻塞理念相悖，用戶體驗差，且存在安全風險。主流瀏覽器已將其移除。
替代方案：
- HTML <dialog> 元素: 一個原生的模態對話框元素，可以通過 showModal() 方法打開。
- JavaScript庫/框架的模態組件: 如Bootstrap Modals, Material UI Dialogs等。
- 自定義CSS和JavaScript實現的模態框: 使用 position: fixed 或 absolute，配合遮罩層。
9. navigator.plugins 和 navigator.mimeTypes
為什么廢棄/不推薦：這兩個API用于檢測瀏覽器安裝的插件（如Flash Player, Java Applets）。隨著NPAPI插件技術的淘汰（主要出于安全和性能考慮），這些API的實用性已大大降低。現代Web技術（如HTML5, CSS3, WebAssembly）已經取代了大多數插件的功能。
替代方案：
通常不需要直接替代。如果需要檢測特定功能，應使用特性檢測（feature detection）而不是插件檢測。例如，檢測瀏覽器是否支持某個視頻格式，而不是檢測是否有某個視頻插件。
10. Performance.timing
為什么廢棄：performance.timing 對象提供了頁面加載過程中的各種時間戳（如 navigationStart, domContentLoadedEventEnd）。雖然它仍然可用，但已被更精確和更全面的 PerformanceNavigationTiming 接口所取代。PerformanceNavigationTiming 提供了更高精度的時間戳，并且可以通過 performance.getEntriesByType('navigation') 獲取，這與其他的 Performance API（如 PerformanceResourceTiming）保持一致。
替代方案：
performance.getEntriesByType('navigation'): 返回一個包含 PerformanceNavigationTiming 對象的數組（通常只有一個元素）。
// 舊方式 (仍可用，但不推薦用于新代碼)
// const timing = window.performance.timing;
// console.log(`DOM content loaded: ${timing.domContentLoadedEventEnd - timing.navigationStart}ms`);
// 推薦方式
const navigationEntry = performance.getEntriesByType('navigation')[0];
if (navigationEntry) {
console.log(`DOM content loaded (new): ${navigationEntry.domContentLoadedEventEnd}ms from navigationStart`);
// 注意：PerformanceNavigationTiming 的時間戳通常是相對于 navigationStart (time origin) 的，
// 而不是像 performance.timing 那樣是絕對時間戳。
// navigationEntry.domContentLoadedEventEnd 是一個 DOMHighResTimeStamp。
}
