javascript 不支持 #ifdef/#ifndef，但可通过构建时预定义（如 webpack defineplugin）、运行时判断（如 process.env.node_env）或注释标记+构建工具移除来模拟；前者使代码彻底消失、不参与覆盖率统计，后者保留在 bundle 中但未执行，会被标为“未覆盖”，需区分处理。
JavaScript 本身不支持传统 C/C++ 风格的 #ifdef/#ifndef 条件编译，但开发者常通过以下方式模拟类似效果：
- 构建时预定义常量（如 Webpack 的
DefinePlugin、Vite 的define） - 运行时环境判断（如
process.env.NODE_ENV === 'development'） - 注释标记 + 构建工具移除（如
/*#__PURE__*/或自定义 babel 插件）
这些做法会直接影响代码覆盖率统计结果——不是因为“编译器跳过”，而是因为被移除的代码在运行时根本不存在，自然无法被覆盖。
条件逻辑是否参与覆盖率统计，取决于它是否实际进入执行环境
如果某段代码在构建阶段就被静态移除（例如用 DefinePlugin 替换为 false 后，整个 if (DEBUG) { console.log(...) } 被整块删掉），那它不会出现在最终 bundle 中，覆盖率工具（如 Chrome Coverage 面板、Istanbul）也就无从统计。这种属于 dead code，和覆盖率无关，应交由 Tree Shaking 或 dead code elimination 处理。
但如果只是运行时判断（比如 if (window.__DEV__) {...}），且该变量在测试环境里为 false，那么这段代码虽保留在 bundle 中，却从未执行——此时它会被覆盖率工具标为“未覆盖”（红色），属于典型的 冗余代码（redundant code），需要你主动识别并处理。
如何避免条件逻辑干扰覆盖率解读
✅ 明确区分“构建期剔除”和“运行时不执行”
前者不计入覆盖率分母（代码已消失），后者计入但未命中（需补测试或豁免）✅ 对构建时注入的布尔常量，统一用可测变量替代
比如不用if (PRODUCTION)，改用if (isProduction())，并在测试中 mockisProduction返回true/false，确保两种路径都被执行✅ 在覆盖率报告中合理使用豁免注释
Istanbul 支持/* istanbul ignore if */、/* istanbul ignore next */等，适用于明确不需测试的环境分支（如仅在 Electron 主进程中运行的初始化逻辑）✅ 利用多环境 CI 构建 + 多份覆盖率合并
分别在development和production模式下跑测试，生成两份覆盖率报告，再用nyc merge合并分析，能更真实反映全路径覆盖情况
实际例子：一个易被误判的条件日志
// webpack.DefinePlugin 将 DEBUG 替换为 false
if (DEBUG) {
console.debug('调试信息');
}
构建后等价于：
if (false) {
console.debug('调试信息');
}
现代打包器（如 Webpack/Terser）会直接删除整个 if (false) 块。所以这段代码既不会影响体积，也不会出现在覆盖率报告中——它压根没进去。
但如果你写成：
const DEBUG = process.env.NODE_ENV === 'development';
if (DEBUG) {
console.debug('调试信息');
}
且测试只在 test 环境运行（NODE_ENV=test），那 DEBUG 为 false，该 if 块就变成“存在但未执行”，覆盖率工具会把它标红。这时你要么补一个 NODE_ENV=development 的专项测试，要么加 /* istanbul ignore if */ 显式豁免。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
