JS代码覆盖率底层原理是通过AST精准识别语句、分支、函数，在其前插入计数代码（如s[12]++、b5++、f[3]++），存入随机命名的全局对象，测试后汇总生成报告；插桩无损业务逻辑，主流工具如Istanbul基于Babel预编译实现。
JS 代码覆盖率的底层原理，核心就一个动作：在你原来的代码里悄悄“加几行计数小纸条”。不是改逻辑，不增功能，也不影响运行结果——就像在高速公路边装摄像头，车怎么开、多快、走哪条道，全都不干涉，只默默记下“这段路有没有车经过”。
插桩到底插了什么？
它不是往函数里塞 console.log，而是用 AST（抽象语法树）精准识别出每一行语句、每一个 if 分支、每一个函数入口，在它们前面自动插入类似这样的计数代码：
- s[12]++ —— 表示第 12 号语句被执行了一次
- b[5][0]++ —— 表示第 5 个 if 的“真分支”走了一次
- f[3]++ —— 表示第 3 个函数被调用了
所有这些计数都存在一个全局对象里（比如 __cov_abc123），名字随机生成，避免和你的变量冲突。测试跑完，这个对象里就存满了“谁被跑了几次”的原始数据。
为什么必须插桩？不插行不行？
JavaScript 引擎本身不提供“这段代码是否执行过”的公开钩子。V8 虽然后来内置了 coverage API（v8 provider），但它只到函数/脚本粒度，无法精确到某一行或某个 else 分支。要达到语句级、分支级覆盖率，目前最可靠的方式仍是插桩——本质是把“被动观察”变成“主动记录”。
类比一下：你想知道图书馆哪本书被借阅过，但管理员不给你借阅日志。你只能在每本书扉页贴一张便签：“有人翻开我，就划一笔”。插桩就是贴便签的过程。
插桩后代码还是原来的代码吗？
是的，业务逻辑完全不变。插桩只加统计，不改返回值、不改流程、不抛异常。比如：
原代码：
function multiply(a, b) { return a * b; }
插桩后：
function multiply(a, b) { cov().f[0]++; cov().s[0]++; return a * b; }
你调 multiply(2, 3)，结果还是 6；只是背后多记了两笔：函数进了、第一行语句也执行了。这就是“无损插桩”的关键——记录归记录，干活归干活。
插桩是谁干的？常见工具有哪些？
主流工具如 Istanbul（Jest 默认）、JSCover、Blanket.js 都做同一件事，只是时机和方式不同：
- Istanbul：测试前用 Babel 插件预编译插桩（推荐，稳定可控）
- JSCover：读取源码文件，生成一份带桩的新 JS 目录（适合 Selenium 端到端场景）
- Blanket.js：运行时动态拦截并插桩（浏览器中开箱即用，但兼容性略弱）
它们底层都依赖 JS 解析器（如 esprima、acorn）先把代码转成 AST，再遍历节点，在合适位置注入计数逻辑——这比正则替换安全得多，不会误伤字符串或注释里的伪代码。
