caniuse.com需按特性而非标签名搜索，优先选带✅及含“HTML/Elements”的条目；兼容性分层，需检测具体API如HTMLDialogElement而非UA；本地用headless浏览器命令快速验证真实渲染行为。
直接查 caniuse.com 比看文档快得多，但得会搜对关键词
浏览器兼容性不是“支持/不支持”二选一，而是按特性、版本、前缀、行为差异分层的。直接搜 HTML 标签名（比如 dialog）往往返回零散结果，因为 caniuse.com 主要按 特性（feature） 归类，而不是按标签名索引。
实操建议：
- 遇到新标签（如
details、meter），先想它解决什么问题：是“原生折叠面板”？搜details element；是“进度/范围可视化”？搜progress meter - 避免搜
html5 tags这类宽泛词——结果包含上百项，无法快速定位 - 在
caniuse.com搜索框输关键词后，优先点进带 ✅ 图标、标题含 “HTML” 或 “Elements” 的条目（例如 “HTMLdialogelement”） - 注意看 “Notes” 栏：Safari 15.4+ 才支持
dialog.showModal()的preventScroll选项，但页面上不写这个参数就完全不影响基础可用性
dialog 这种“看似简单”的标签，实际兼容陷阱最多
它在 Chrome 33+、Edge 79+、Firefox 98+ 原生支持，但 Safari 直到 16.4 才加，且早期版本（16.0–16.3）只支持 showModal()，不支持 close() 触发 close 事件——这意味着你用 myDialog.close() 关闭后，监听 dialog.addEventListener('close', ...) 在 Safari 16.2 下根本不会执行。
应对方式：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
close事件做关键逻辑，改用myDialog.open = false后手动触发清理 - 检测时别只查
dialog，顺手查dialog element页面右下角的 “Related features” —— 里面列了HTMLDialogElement、showModal()等子特性，各自支持度不同 - 用
typeof HTMLDialogElement !== 'undefined'判断比'showModal' in document.createElement('dialog')更可靠，后者在 Safari 16.0–16.3 返回true但调用会报错
用 feature detection 代替 browser detection，但得检测对 API
写 if (navigator.userAgent.includes('Safari')) 是危险的——iOS WebView、Mac Catalyst、甚至某些安卓壳浏览器都可能上报 Safari UA，但根本不支持 inert 属性。真正该测的是运行时能力。
常见误检和正解：
- 错：用
'inert' in document.body判断inert支持 → 返回false即使浏览器已支持（Chrome 122+），因为该属性不在body上，而在任意元素上 - 对：创建临时元素
const el = document.createElement('div'); el.inert = true; return 'inert' in el; - 错：查
document.createElement('picture').srcset是否存在 →srcset是img和source的属性，picture元素本身没有 - 对：测
HTMLPictureElement构造函数是否存在，再结合document.createElement('source').srcset !== undefined
本地快速验证：用一行命令跑真实环境检测
光看 caniuse.com 不够，有些 bug（比如 Firefox 对 input[type=color] 的 value 初始化行为）只在真实渲染中暴露。不用搭完整测试页，终端里就能试：
echo '<input type="color" value="#ff0000">' | chromium --headless --dump-dom --no-sandbox 2>/dev/null | grep -o 'value="[^"]*"
这行命令能立刻看到 Chromium 渲染后 input 的实际 value 属性值，对比 Firefox 或 Safari 的结果（把 chromium 换成对应命令）。适合验证：
- 自定义元素是否被升级（
customElements.get('my-button')返回undefined？） -
contenteditable在不同浏览器中是否触发input事件 -
formdata事件是否在提交前可修改数据
复杂点在于，很多特性（比如 popover 的锚点定位、container queries 的尺寸计算）必须在真实布局流中才能观察，这时候截图 + getComputedStyle 比单纯查 DOM 更有效。
