finally块不产生分支覆盖率问题，因其语义是确定性执行的清理段落，Istanbul仅统计其语句/行覆盖，不将其视为分支节点。
JavaScript 中的 try-finally 块本身没有“分支”逻辑（不像 if 或 try-catch 那样有多个可选执行路径），所以主流覆盖率工具（如 Istanbul/nyc）**默认不为 finally 块单独统计分支覆盖率（branch coverage）**，也不会将其视为一个需要“覆盖两种情况”的分支节点。
为什么 finally 不产生分支覆盖率问题
finally 块的设计语义是：无论 try 块是否抛出异常、是否提前 return、是否正常结束，finally 都会执行（除非进程被强制终止，如 process.exit() 或崩溃）。它不是条件分支，而是确定性执行的清理段落。
因此：
- Istanbul 将
finally视为“语句（statement）”和“行（line）”，只统计是否被执行（即语句/行覆盖率）； - 它不生成额外的分支节点（branch node），所以不会出现在
branches统计中； - 即使你只测试了
try正常流程，没测异常路径，finally仍会被计入已覆盖的行/语句——只要它运行过一次。
但要注意：异常 + return 的组合可能“隐藏”finally 执行
虽然 finally 总是执行，但它的执行时机和返回值可能影响外层行为，进而让某些测试看似“跳过了 finally”。常见易错点：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
try中return+finally中也return→ 外层函数返回的是finally的值，try的return被覆盖； -
try抛错 +catch中throw或return+finally有副作用 →finally仍执行，但错误可能被吞掉或重抛； -
finally中抛错 → 会中断原有异常链，覆盖try/catch的错误。
这些场景下，finally 依然执行了（语句覆盖达标），但若未编写对应测试用例（例如没测异常流），可能导致逻辑缺陷——这属于**功能覆盖不足**，而非分支覆盖率缺失。
如何确保 finally 行为真正被验证
既然工具不强制你“分支覆盖 finally”，那就靠测试设计来保障其健壮性：
- 对每个含
finally的函数，至少写两个测试：一个走正常流程（try成功），一个走异常流程（try抛错，且无catch或catch后继续传播）； - 在
finally中做关键操作（如关闭连接、释放锁、重置状态）时，用jest.mock()或 sinon 模拟依赖，并断言其方法被调用； - 利用 Istanbul 的「行覆盖率」报告，确认
finally块内每一行都被点亮（特别是多行finally）； - 避免在
finally中写可能抛错的复杂逻辑——若必须，应包裹try-catch并单独测试。
补充：try-catch-finally 的分支覆盖实际在哪
真正产生分支覆盖率的是 catch 和（隐式）异常路径：
-
try块本身：0 分支； - 每个
catch子句：1 个分支（“是否匹配该异常类型”）； - 是否存在
catch：决定是否有“异常未被捕获”路径（影响整体 branch count）； -
finally：始终 0 分支，仅贡献 statement/line 覆盖。
你可以用 nyc --reporter=html 生成报告，在 HTML 中点击源码，观察 catch 行前是否有橙色/红色标记（表示该分支未执行），而 finally 行只会显示绿色（执行过）或灰色（未执行）。
