JavaScript 作為一門不斷發(fā)展的語言，其API也在持續(xù)進(jìn)化。新的、更安全、更高效的API不斷涌現(xiàn)，而一些舊的API則因為各種原因（如安全問題、性能瓶頸、設(shè)計缺陷或有了更好的替代品）被標(biāo)記為“廢棄”（Deprecated）。繼續(xù)使用這些廢棄的API可能會導(dǎo)致兼容性問題、安全漏洞，或者讓我們的代碼難以維護(hù)。

1. document.execCommand()

為什么廢棄/不推薦：document.execCommand() 曾是實現(xiàn)富文本編輯（如加粗、斜體、復(fù)制、粘貼）的主要方式。然而，它的行為在不同瀏覽器之間存在顯著差異，API本身也難以擴展和維護(hù)。更重要的是，它存在潛在的安全風(fēng)險（例如，不當(dāng)使用可能導(dǎo)致XSS攻擊）。W3C已明確表示不再推薦使用此API，并鼓勵開發(fā)者轉(zhuǎn)向更現(xiàn)代的解決方案。

替代方案：

• Clipboard API (navigator.clipboard): 用于異步復(fù)制和粘貼文本或數(shù)據(jù)，更安全、更現(xiàn)代。
• Selection API: 用于獲取和修改用戶當(dāng)前選中的文本或范圍。
• 直接操作DOM: 對于富文本編輯，許多現(xiàn)代編輯器庫（如Quill, Slate.js, Draft.js）或自定義邏輯會直接操作DOM來實現(xiàn)所需效果。

// 不推薦
// document.execCommand('copy');

// 推薦 (復(fù)制文本)
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()

為什么廢棄：這兩個函數(shù)用于URL編碼和解碼，但它們存在嚴(yán)重缺陷：

• 它們不會正確處理非ASCII字符（如中文）。
• 它們不會對所有在URL中具有特殊意義的字符進(jìn)行編碼（例如 +, /, @）。

替代方案：

• encodeURIComponent() / decodeURIComponent(): 用于編碼和解碼URL的查詢字符串參數(shù)部分。這是最常用的，因為它會對所有必要的字符進(jìn)行編碼。
• encodeURI() / decodeURI(): 用于編碼和解碼整個URI。它們不會對一些URI中合法的特殊字符（如 :, /, ;, ?）進(jìn)行編碼。

// 不推薦
// const encoded = escape("你好 world?query=1");
// console.log(encoded); // %u4F60%u597D%20world%3Fquery%3D1 (非ASCII字符處理不當(dāng))

// 推薦
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%20world

3. 同步的 XMLHttpRequest

為什么不推薦：在 XMLHttpRequest 的 open() 方法中將第三個參數(shù)（async）設(shè)置為 false 會發(fā)起一個同步請求。這會阻塞JavaScript主線程，直到請求完成，導(dǎo)致瀏覽器界面凍結(jié)，用戶體驗極差。現(xiàn)代Web開發(fā)強烈推薦使用異步操作。

替代方案：

• 異步 XMLHttpRequest: 默認(rèn)行為，使用回調(diào)函數(shù)或Promise處理響應(yīng)。
• fetch API: 更現(xiàn)代、基于Promise的API，提供了更簡潔和強大的網(wǎng)絡(luò)請求方式。

// 極不推薦
// const xhr = new XMLHttpRequest();
// xhr.open('GET', '/api/data', false); // false 表示同步
// xhr.send();
// if (xhr.status === 200) {
//   console.log(xhr.responseText); // 阻塞直到響應(yīng)
// }

// 推薦 (使用 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標(biāo)準(zhǔn)標(biāo)記為“l(fā)egacy feature”（遺留特性），主要是因為其第二個參數(shù)（子串長度）與其他字符串提取方法（如 substring 和 slice，它們的第二個參數(shù)是結(jié)束索引）不一致，容易造成混淆。

替代方案：

• String.prototype.substring(indexStart, indexEnd): 提取 indexStart 到 indexEnd（不包括）之間的字符。
• String.prototype.slice(beginIndex, endIndex): 與 substring 類似，但可以接受負(fù)數(shù)索引（表示從字符串末尾開始計數(shù)）。

5. Event.keyCode, Event.which, Event.charCode

為什么廢棄：這些屬性用于獲取鍵盤事件中按下的鍵。然而，它們的值在不同瀏覽器、不同操作系統(tǒng)甚至不同鍵盤布局下都可能不一致，導(dǎo)致兼容性問題和開發(fā)困擾。

替代方案：

• Event.key: 返回一個表示按鍵物理值的字符串（例如 "a", "Enter", "ArrowUp"）。這是最推薦的方式，因為它更直觀且具有更好的國際化支持。
• Event.code: 返回一個表示物理按鍵代碼的字符串（例如 "KeyA", "Enter", "ArrowUp"），不受鍵盤布局影響。

6. window.event (全局事件對象)

為什么不推薦：在舊的IE瀏覽器事件模型中，事件對象是通過全局的 window.event 訪問的?，F(xiàn)代瀏覽器遵循W3C標(biāo)準(zhǔn)，將事件對象作為第一個參數(shù)傳遞給事件處理函數(shù)。依賴全局 window.event 會導(dǎo)致代碼在非IE舊版瀏覽器或嚴(yán)格模式下失效。

替代方案：使用傳遞給事件處理函數(shù)的事件對象

7. String.prototype.trimLeft() 和 String.prototype.trimRight()

為什么廢棄：這兩個方法用于移除字符串開頭或結(jié)尾的空白字符。它們已被ECMAScript標(biāo)準(zhǔn)采納，但名稱更改為 trimStart() 和 trimEnd() 以獲得更好的語義一致性（與 padStart() 和 padEnd() 等方法對齊）。雖然舊名稱在很多瀏覽器中仍可作為別名使用，但推薦使用標(biāo)準(zhǔn)名稱。

替代方案：

• String.prototype.trimStart()
• String.prototype.trimEnd()

8. Window.showModalDialog()

為什么廢棄：showModalDialog() 用于打開一個模態(tài)對話框，它會阻塞父窗口的JavaScript執(zhí)行，直到對話框關(guān)閉。這種阻塞行為與現(xiàn)代Web應(yīng)用的異步、非阻塞理念相悖，用戶體驗差，且存在安全風(fēng)險。主流瀏覽器已將其移除。

替代方案：

• HTML <dialog> 元素: 一個原生的模態(tài)對話框元素，可以通過 showModal() 方法打開。
• JavaScript庫/框架的模態(tài)組件: 如Bootstrap Modals, Material UI Dialogs等。
• 自定義CSS和JavaScript實現(xiàn)的模態(tài)框: 使用 position: fixed 或 absolute，配合遮罩層。

9. navigator.plugins 和 navigator.mimeTypes

為什么廢棄/不推薦：這兩個API用于檢測瀏覽器安裝的插件（如Flash Player, Java Applets）。隨著NPAPI插件技術(shù)的淘汰（主要出于安全和性能考慮），這些API的實用性已大大降低?，F(xiàn)代Web技術(shù)（如HTML5, CSS3, WebAssembly）已經(jīng)取代了大多數(shù)插件的功能。

替代方案：

通常不需要直接替代。如果需要檢測特定功能，應(yīng)使用特性檢測（feature detection）而不是插件檢測。例如，檢測瀏覽器是否支持某個視頻格式，而不是檢測是否有某個視頻插件。

10. Performance.timing

為什么廢棄：performance.timing 對象提供了頁面加載過程中的各種時間戳（如 navigationStart, domContentLoadedEventEnd）。雖然它仍然可用，但已被更精確和更全面的 PerformanceNavigationTiming 接口所取代。PerformanceNavigationTiming 提供了更高精度的時間戳，并且可以通過 performance.getEntriesByType('navigation') 獲取，這與其他的 Performance API（如 PerformanceResourceTiming）保持一致。

替代方案：

performance.getEntriesByType('navigation'): 返回一個包含 PerformanceNavigationTiming 對象的數(shù)組（通常只有一個元素）。

// 舊方式 (仍可用，但不推薦用于新代碼)
// 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。
}