JavaScript覆盖率工具无法直接忽略错误处理块，但可通过istanbul注释（如// istanbul ignore next）、抽离可测错误函数、调整阈值等间接方式降低其对覆盖率目标的干扰。
在 JavaScript 代码覆盖率工具（如 Istanbul / nyc / c8）中，无法直接“忽略错误处理块”（比如 catch 或 finally 中的逻辑）的覆盖率统计，因为这些块本身是可执行代码，工具默认会将其纳入统计范围。但你可以通过以下方式**间接降低它们对覆盖率目标的干扰**，让报告更聚焦于主业务逻辑。
用 Istanbul 注释指令跳过特定代码行
这是最常用、最可控的方式。在 catch 块前或内部添加特殊注释，告诉 Istanbul 忽略该行或该块：
-
// istanbul ignore next：忽略下一行（常用于
catch (e) { ... }这一行） -
// istanbul ignore else：忽略
else分支（适用于if (...) { ... } else { ... }中的错误兜底） - // istanbul ignore file：忽略整个文件（慎用，仅适用于纯错误上报、监控等辅助模块）
示例：
try {
await api.fetchData();
} catch (e) {
// istanbul ignore next
console.error("API failed:", e);
reportError(e);
throw new UserFriendlyError();
}
这样，catch 块内的语句不会参与行覆盖、分支覆盖等统计，也不会拉低整体覆盖率数值。
立即学习“Java免费学习笔记（深入）”；
合理设计错误处理，避免不可测逻辑
很多错误处理块难以覆盖，是因为它们依赖真实异常（如网络中断、磁盘满），而单元测试中很难稳定复现。解决思路不是绕过覆盖率，而是让错误路径变得可测：
- 把错误处理逻辑抽成独立函数（如
handleApiError(e)），然后单独为其写测试 - 在主流程中用依赖注入或 mock 替换底层调用，主动抛出错误来触发
catch - 避免在
catch中写副作用强、环境敏感的代码（如直接调用window.alert、修改全局状态）
调整覆盖率阈值与报告策略
如果部分错误处理确实无法也不必覆盖（例如兜底的 process.on('uncaughtException')），可在配置中放宽对应维度的阈值：
- 在
nyc的package.json或.nycrc中，为branches或functions单独设更低的阈值 - 使用
--check-coverage --lines 90 --functions 85 --branches 75等组合，不强求所有维度都 100% - 启用
reporter: ['text', 'html']，结合 HTML 报告人工确认：哪些catch是真正未覆盖，哪些是已用注释排除
注意：不要滥用 ignore 注释
随意加 // istanbul ignore next 会让覆盖率失去意义。只在以下情况使用：
- 错误处理纯粹是日志/监控上报，无业务判断
- 兼容性降级代码（如
try { new AbortController() } catch { ... }） - Node.js 特定版本才执行的分支，且当前测试环境无法模拟
核心原则是：**可测试的错误路径要测，不可测或非业务关键的才考虑排除。**
