JavaScript功能检测与降级方案解析

本文深入探讨了在现代Web开发中如何通过功能检测而非浏览器嗅探来实现更可靠、更可持续的兼容性策略，强调用 `in`、`typeof`、`instanceof`（辅以 `Object.prototype.toString`）精准判断JavaScript API可用性，结合 `CSS.supports()` 和运行时样式验证应对CSS特性差异，借助 `try...catch` 安全试探易失败的新API，并利用动态 `import()` 按需加载polyfill以优化首屏性能；同时提醒开发者警惕检测逻辑自身在极端老旧环境（如IE8）中的失效风险，真正践行“核心功能有退路、体验渐进不妥协”的优雅降级哲学。

功能检测比浏览器嗅探更可靠，降级处理的关键不是“兼容所有旧版”，而是“让核心功能在不支持的环境里有合理退路”。

用 in、typeof 和 instanceof 判断 API 是否可用

不要查 navigator.userAgent，直接测目标特性是否存在。比如检测 fetch：

if ('fetch' in window) {
  fetch('/api/data').then(r => r.json());
} else {
  // 降级到 XMLHttpRequest
  const xhr = new XMLHttpRequest();
  xhr.open('GET', '/api/data');
  xhr.onload = () => JSON.parse(xhr.responseText);
  xhr.send();
}

注意点：

• 'fetch' in window 比 typeof fetch !== 'undefined' 更稳妥，因为某些 IE 模式下 fetch 可能被声明但未定义
• 对构造函数（如 Promise）优先用 typeof Promise === 'function'，避免某些老环境把 Promise 当作全局变量但未初始化
• instanceof 在跨 iframe 场景会失效，此时改用 Object.prototype.toString.call(obj) === '[object Promise]'

检测 CSS 特性用 CSS.supports() 或 element.style 做运行时判断

不能只靠构建时加前缀，得在运行时确认浏览器是否真能渲染：

if (CSS.supports('display', 'grid')) {
  el.style.display = 'grid';
} else if (CSS.supports('display', 'flex')) {
  el.style.display = 'flex';
} else {
  el.className += ' fallback-grid';
}

常见陷阱：

• CSS.supports() 在 IE 中完全不支持，需先兜底：if (typeof CSS !== 'undefined' && CSS.supports)
• 检测属性值（如 CSS.supports('font-feature-settings', '"ss01"')）比只测属性名（CSS.supports('font-feature-settings', 'normal')）更能反映真实能力
• 有些属性虽存在但行为异常（如 Safari 12 的 gap 在 flex 容器中无效），这时需结合 getComputedStyle(el).display 验证实际生效结果

用 try...catch 捕获语法或 API 调用失败，而非预判环境

某些新语法（如可选链 a?.b）无法通过静态检测，只能执行时试探：

function safeGet(obj, path) {
  try {
    return eval(`obj${path}`); // 仅作示意，生产环境应解析 path 并逐级访问
  } catch (e) {
    return undefined;
  }
}

// 更实用的例子：尝试使用 ResizeObserver
let resizeObserver;
try {
  resizeObserver = new ResizeObserver(cb);
} catch (e) {
  // 降级为 window.onresize + getBoundingClientRect
  window.addEventListener('resize', throttle(cb, 100));
}

关键原则：

• try...catch 适合检测“调用即报错”的 API（如 new AbortController()、structuredClone()），不适合检测语法错误（JS 引擎会在解析阶段抛出 SyntaxError，无法被捕获）
• 避免在 try 块中写大量逻辑，只包裹最小可疑语句，否则掩盖真实问题
• 捕获后不要静默吞掉错误，至少打日志：console.warn('ResizeObserver not supported, using resize event')

模块加载时按需注入 polyfill，而不是全量打包

现代构建工具（如 Webpack、Vite）支持动态 import()，可把 polyfill 拆成异步 chunk：

if (!('IntersectionObserver' in window)) {
  import('./polyfills/io.js').then(({ initIO }) => initIO());
}

// 或更细粒度地只加载缺失部分
if (!Array.prototype.flat) {
  import('array-flat-polyfill');
}

这样做能减少首屏体积，但要注意：

• 动态 import() 返回 Promise，需确保后续逻辑等待它完成（例如用 await import() 或 .then()）
• 某些 polyfill（如 core-js）需在任何业务代码前执行，不能晚于 import './main.js'，否则已有引用会报错
• 像 regenerator-runtime 这类 Babel 运行时，必须在入口文件顶部同步引入，否则 async/await 编译后的代码会找不到 regeneratorRuntime

最常被忽略的一点：功能检测本身也可能被旧环境破坏——比如 IE8 不支持 Array.prototype.forEach，而你又用它来遍历要检测的 API 列表。这时候得用最原始的 for 循环写检测逻辑，或者确保基础工具函数已提前就位。

到这里，我们也就讲完了《JavaScript功能检测与降级方案解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！