100%代码覆盖率不等于无bug，仅表明代码被执行过，无法保证行为正确、边界覆盖或异常处理；它应作为发现未调用函数、失效分支和高风险模块的诊断工具，而非质量担保。
不是。100% 代码覆盖率完全不等于代码没有 Bug。
覆盖率只说明“代码被执行过”，不保证“行为正确”
语句覆盖 100%，只是说每一行都运行了一次；分支覆盖 100%，也只是说每个 if/else、每个 case 都走了一遍。但这些执行过程里：
- 可能没做任何断言，比如
add(2, 3);跑过了函数，却没检查返回值是不是 5； - 可能只测了正常输入，漏掉了
null、undefined、空数组、超大数字等边界情况； - 可能触发了除零、类型错误或竞态条件，但测试没捕获异常或没验证最终状态。
典型反例：一行函数 + 六个测试 = 100% 覆盖，火箭照样爆炸
比如这个计算速度的函数：
return ((3 * (4 * angle - direction)) * 3) / (7 * (direction - (2 * angle))) * -1;
}
只要用六组不触发分母为零的参数跑一遍，就能轻松达成 100% 行覆盖和分支覆盖。但一旦传入 angle=2, direction=4，立刻崩溃——而这个组合在测试中根本没出现。
覆盖率是诊断工具，不是质量担保书
它真正有用的地方，在于帮你发现：
- 未调用的函数：函数覆盖为 0%，大概率是废弃逻辑或死代码；
-
长期未走通的分支：比如
if (user.role === 'admin')在真实流量中从未命中，说明权限模型已失效； - 高风险模块：语句覆盖低但体积大、依赖多的文件，往往是重构优先级最高的地方。
理性使用覆盖率的关键动作
与其追求 100%，不如关注三件事：
- 每次新增逻辑，必须带至少一个能验证结果的断言，而不是只“调用一下”；
- 对关键路径（如支付、登录、数据转换）手动检查分支覆盖报告，补全缺失的真假组合；
- 把覆盖率当重构参照：删代码前确认它是真没执行过，加新测试后确保核心分支不降级。
