请介绍一次你解决浏览器兼容性问题的经历。
五个经典回答示范
我在实习时做过一个校园活动页，测试同学反馈部分低版本安卓浏览器上按钮点了没反应。我先用开发者工具看没有报错，再用特性检测确认是不支持 fetch 的 Promise 语法，最后引入了对应的 polyfill 并做了降级提示。上线后这类反馈归零。这件事让我养成了先定位、再兼容、最后兜底的 habit。
我们一个 B 端项目要求兼容到某个国产浏览器内核。我的做法分三层：构建层用 babel 按浏览器版本转译；运行层对 fetch、CSS 变量这类缺口打 polyfill；页面层对实在无法兼容的极端场景做只读降级并展示提示条。我把兼容清单固化成了 CI 里的 lint 规则，新同学提交代码就能自动拦截不兼容写法。
兼容性问题我一般先问两个问题：用户占比多少、值不值得修。我会用监控平台看报错按浏览器版本的分布，只对超过阈值的版本做兼容，其余走优雅降级。更重要的是建立机制：browserslist 统一管理版本基线、CI 加兼容性检查、线上错误按版本维度告警。兼容不是逐个修 bug，而是把版本策略变成工程约束。
面试官若追问『线上怎么发现兼容性问题』：我会讲错误监控按浏览器版本聚合的实践——同一个 JS 报错在低版本集中出现就是典型信号，配合 sourcemap 能直接定位到语法层面；再追问『polyfill 全量引入体积太大怎么办』，答案是按 browserslist 目标 + core-js 按需注入，或者用动态检测按需加载。
『兼容性问题很常见，我一般就是多写几套 if else，什么浏览器都判断一下，实在不行就让用户换个浏览器。』——点评：只给手段没有方法论，多分支判断会造成维护灾难；让用户换浏览器是把成本转嫁给用户。好的回答应体现定位手段、分层策略和数据驱动取舍。
- 打开 模拟练习，选择「前端开发」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。