动态生成的代码不被统计覆盖率，因其在运行时才产生，无源码路径和ast节点，无法映射行号或分支信息；主流工具仅对静态解析的源文件插桩，而eval、function构造函数等内容作为字符串执行，不参与插桩流程。
动态生成的代码（如 eval、Function 构造函数、模板字符串拼接后执行、运行时编译的表达式等）在 JS 单元测试覆盖率统计中默认不会被纳入统计范围，因为主流覆盖率工具（Jest + Istanbul / V8 Coverage / nyc）只对静态解析到的源文件进行插桩（instrumentation），而动态代码在运行时才产生，没有对应的原始源码路径和 AST 节点，无法映射行号或分支信息。
为什么动态代码不被统计？
覆盖率工具依赖源码插桩：在测试前，Istanbul 会读取 .js/.ts 文件，插入计数器（如 __coverage__.s[1]++），再交给测试环境执行。而 eval('x + y') 或 new Function('return a * b') 的内容是字符串，不经过插桩流程，执行时就像“黑盒”，V8 引擎只执行字节码，不反馈哪一行被覆盖。
Chrome DevTools Coverage 面板也无法标记 eval 内容——它只识别已加载的脚本资源（<script src></script> 或 import 模块），不追踪字符串求值过程。
哪些场景属于“动态生成代码”？
-
eval(codeString)或window.eval() new Function(arg1, arg2, bodyString)- 使用
vm.runInNewContext（Node.js）执行字符串代码 - 某些模板引擎（如早期 EJS、Handlebars 编译后生成函数）的 runtime 编译结果
- 通过
document.createElement('script').textContent = ...注入并执行的代码
如何应对？分情况处理
① 尽量避免在生产逻辑中使用动态代码
这是最根本的解法。动态执行破坏可测试性、可调试性和安全性。用配置对象、策略模式、AST 解析（如 acorn）或预编译替代。例如：
const calc = new Function('a', 'b', 'return a ' + operator + ' b');
const ops = { '+': (a,b) => a + b, '-': (a,b) => a - b };const result = ops[operator]?.(a, b);
② 若必须保留，将动态部分抽离为独立模块并显式测试
把字符串模板或表达式编译逻辑封装成函数，导出其生成结果，并对生成函数做单元测试（注意：生成函数本身仍无法被插桩，但你可以测它的输入输出行为）：
例如一个简易表达式求值器：
src/evaluator.jsexport function compileExpression(expr) {<br> return new Function('data', `return ${expr}`);<br>}
测试时验证编译行为是否符合预期：
test('compileExpression returns correct function', () => {<br> const fn = compileExpression('data.x + data.y');<br> expect(fn({ x: 2, y: 3 })).toBe(5);<br>});
这样虽不能提升“动态代码行”的覆盖率数字，但保障了动态逻辑的正确性，且该测试本身会被统计（提高外围模块覆盖率）。
③ 对极少数不可替代的 eval 场景，手动排除 + 文档标注
若业务强依赖（如低代码平台的公式引擎），可在覆盖率配置中明确排除相关文件或目录，避免拉低整体指标误导判断：
- Jest：
coveragePathIgnorePatterns: ['<rootdir>/src/evaluators/']</rootdir> - Vitest：
exclude: ['src/evaluators/**']
同时在代码注释中标明：// NOTE: This file uses eval → excluded from coverage; correctness ensured via integration tests。
补充：不要尝试“强行插桩”动态代码
有人试图用 eval(require('istanbul-lib-instrument').instrumentSync(code)) 动态插桩字符串——这不仅极其脆弱（破坏 sourcemap、报错难定位），还会引入严重安全风险（插桩后的字符串仍可被任意执行），且 Jest/Vitest 不支持运行时重插桩。不建议。
