JavaScript中10个“过时”的API，你的代码里还在用吗？

JavaScript , , , ,

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%20world

3. 同步的 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。
    }