最近社区里关于“拒绝 SSR 的伪繁荣”和“拒绝 Sidekiq 的伪繁荣”的讨论直击痛点。正如大家在讨论中提到的，LLM 创新已进入“工程化兑现期”，我们不再单纯追求“能力展示”，而是转向“交付可靠性”。在前端架构上，我们反思 SSR 是否真的带来了性能红利；在后端任务治理中，我们反思队列吞吐量是否掩盖了失败重试的隐患。这让我联想到代码质量度量中的一个重灾区——代码覆盖率。

在许多工程团队中，代码覆盖率（Code Coverage）常常被视为质量的银弹。看着 CI 流水线中 90% 甚至 100% 的绿色数字，就像看着 Sidekiq 队列瞬间清零一样，给人一种虚假的安全感。然而，高覆盖率并不等同于高可靠性。如果测试只是走马观花地执行了每一行代码，却未验证逻辑分支的边界条件，这种“繁荣”便是脆弱的。

要打破这种“伪繁荣”，我们需要将策略从单纯的“行覆盖率”升级为更具工程意义的“分支覆盖率”与“变更覆盖率”。

首先，行覆盖率具有欺骗性。例如，一段包含复杂布尔逻辑的代码，只要一个测试用例通过，行覆盖率就能达到 100%，但可能完全遗漏了 false 的分支。在工程化兑现期，我们需要关注代码逻辑的完备性。

以 Jest 配置为例，我们应当在配置中强制开启分支覆盖率检查，并设定合理的阈值：

// jest.config.js
module.exports = {
  collectCoverage: true,
  coverageThreshold: {
    global: {
      branches: 80, // 强制要求 80% 的分支覆盖率
      functions: 80,
      lines: 80,
      statements: 80,
    },
  },
  collectCoverageFrom: [
    "src/**/*.{js,ts}",
    "!src/**/*.d.ts", // 排除类型定义
    "!src/mocks/**", // 排除模拟数据
  ],
};

其次，正如论坛中提到的“系统可靠性成为第一能力”，我们在治理遗留代码时，不应苛求整体覆盖率的提升，而应聚焦于“增量质量”。引入 Diff Coverage（差异覆盖率）工具，确保每一次新的代码提交都在可控的质量范围内，避免为了追求整体数字而编写无效的测试。

以下是一个利用 diff-cover 在 CI 环境中仅检查新增代码覆盖率的示例：
 

# 1. 生成覆盖率报告
pytest --cov=./src --cov-report=xml

# 2. 检查与主分支的差异覆盖率
# 要求新代码的分支覆盖率必须达到 100%，否则 CI 失败
diff-cover coverage.xml --compare-branch=origin/main --fail-under=100

这种策略将我们的注意力从“修复旧债”转移到“不再增加新债”，这与产品工程从“做出智能效果”转向“把智能系统稳定运营起来”的思路是一致的。高质量的测试应当是系统的免疫系统，而非仅仅是一张漂亮的体检表。

在追求系统可靠性的今天，我们是否应该重新定义“测试通过”的标准？如果你的项目明天要上线核心功能，你会更看重 90% 的历史行覆盖率，还是 100% 的新增核心路径分支覆盖率？