功能检测比浏览器嗅探更可靠，应通过 in、typeof、instanceof 等直接检测 API 是否可用，结合 CSS.supports()、try...catch 和动态 import() 实现渐进增强与合理降级。
功能检测比浏览器嗅探更可靠，降级处理的关键不是“兼容所有旧版”，而是“让核心功能在不支持的环境里有合理退路”。
用 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 做运行时判断
不能只靠构建时加前缀，得在运行时确认浏览器是否真能渲染：
立即学习“Java免费学习笔记（深入）”；
if (CSS.supports('display', 'grid')) {
el.style.display = 'grid';
} else if (CSS.supports('display', 'flex')) {
el.style.display = 'flex';
} else {
el.className += ' fallback-grid';
}
常见陷阱：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
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 循环写检测逻辑，或者确保基础工具函数已提前就位。
