没有全浏览器兼容的银弹，需识别差异、按需降级、用现代工具收口：JS要运行时检测API存在性并fallback，CSS/DOM注意隐蔽差异，Babel和polyfill须正确配置，且兼容范围应依实际目标而定。
没有“一份代码全浏览器兼容”的银弹，关键在于识别差异、按需降级、用现代工具收口。
识别哪些 API 在旧浏览器里根本不存在
比如 fetch 在 IE 完全不可用，Promise 在 IE11 以下不支持，Array.from 在 IE 中返回 undefined。不能只看 MDN 上的“兼容性表格”，还要验证运行时是否存在。
- 上线前用
typeof fetch !== 'function'或!window.Promise做存在性判断，别直接调用 - 对核心功能（如登录请求）做 fallback：存在
fetch就用，否则退到XMLHttpRequest - 避免在构造函数里直接写
new Promise(...)，先检查window.Promise
CSS 和 DOM 行为差异比 JS 更隐蔽
IE 的 getBoundingClientRect() 返回值不含 x/y，Firefox 对 input[type=number] 的 valueAsNumber 处理更严格，Safari 15.4 之前不支持 ResizeObserver 构造函数传参对象。
- 获取元素位置优先用
elem.getBoundingClientRect().top而非.y，后者在 IE 报错 - 设置表单值后读取数值，统一用
parseFloat(elem.value) || 0，不依赖valueAsNumber - 用
new ResizeObserver(callback)时，不要传第二个参数对象（如{box: 'border-box'}），IE 和旧 Safari 不认
转译和 polyfill 不是开箱即用的
Babel 默认只处理语法（如箭头函数、解构），不注入 Array.prototype.includes 这类实例方法；core-js 的引入方式稍有偏差，就可能漏掉 Map 或 Symbol。
立即学习“Java免费学习笔记（深入）”；
- 在入口文件顶部加
import 'core-js/stable'; import 'regenerator-runtime/runtime';，别只 import 某个模块 - Babel 配置中
targets要明确写{ie: '11'}，光写last 2 versions会忽略 IE -
webpack打包后检查生成代码是否含var _Promise = window.Promise;类型的注入，没有说明 polyfill 没生效
真正难的不是写兼容代码，而是判断“这里到底要不要兼容”。一个内部管理系统支持到 Chrome 80 就够了，但银行网银页面可能还得跑在 IE10 上——目标定了，polyfill 才不会堆成债。
