背景
图片懒加载、列表触底加载、内容无限滚动，目标元素进入视口动画播放等
项目中实际开发场景、
浏览器中列表触底加载解决方案：
- 监听滚动条
- 浏览器滚动触发频率太高（缺点1）
- 添加抖动后接口会有延迟（缺点2）
- intersectionObserver
旧的解决方法
判断某个元素是否进入“视口”(viewport)，通常会使用getBoundingClientRect()方法获取相关元素的位置信息，并且还会用到事件监听。但是getBoundingClientRect()方法时运行在主线程，频繁触发，调用会造成性能问题。
intersection Observer API方法是异步的，不影响主线程的执行效率。
IE和safari不支持InterpObserver API
兼容性判断浏览器
if(window?.IntersectionObserver){
}
不支持，使用polyfill
主题、重点
做检查浏览器API兼容性的工具
背景
线上用户反馈页面出现白屏，通过JSError日志 排查发现很多类似InterpObserver is not defined的日志。最近一次修改代码时间线吻合。定位到浏览器InterpObserver API做DOM曝光时没有考虑到兼容性问题。
解决方案
通过增加polyfill方式解决这个问题
思考
随着操作系统和浏览器的更新，越来越多的JS/浏览器的新特性，为前端开发带来便利，也会出现一些兼容性问题。所以想开发一个集成现有的兼容性检查规则的工具将这个过程自动化。
详细过程
了解了前端兼容性检查网站：Caniuse和MDN。常规的API的调用方式只有几种：NewExpression(构造表达式)和CallExpression（调用表达式）。
利用browserlist配置执行目标检查的浏览器范围。接入发布流程的管控，
学习到什么
了解Babel parse AST的过程
解析AST过程有两个阶段：词法分析和语法分析 = 词法分析阶段：字符串形式的代码转换为令牌流，令牌类似于AST中的节点
- 语法分析阶段：把一个令牌流转化为AST的形式，同时把令牌中的信息转化为AST的表述结构
AST遍历的过程
Babel在处理一个节点时，是以访问者的形式获取节点信息并进行相关操作。
