覆盖率 90% 也防不住线上 bug，变异测试怎么低成本落地到 CI

【背景】 我做了 5 年测试开发，现在维护一条 B 端 SaaS 的核心计费链路（Java 17 + JUnit 5 + Spring Boot 3，接口自动化 pytest + httpx 约 1200 条用例，跑在共享 staging）。我们 CI 里单测行覆盖长期 90%+、分支覆盖 85%+，回归全绿率也高。但过去一年线上还是出了 3 次 P2，复盘下来都不是「没覆盖到」，而是「断言太弱」——比如把 >= 写成 >、漏掉一个 != 判空，覆盖率照样是绿的。

【现象】

• 覆盖率数字很漂亮，但抓不住「逻辑写反 / 边界差一 / 条件取反」这类 bug；
• 加用例只能加行覆盖，加不动「这条断言到底有没有真的校验到语义」；
• 团队里有人提过用变异测试（mutation testing）来衡量断言有效性，但没人真正跑起来过。

【已尝试的排查与结果】

1. 把重点接口的断言从「200 + 字段非空」改成逐字段精确断言，有用但靠人肉 review，难持续；
2. 试过用 PIT（pitest）对一个 200 行的核心计价类跑变异，变异杀死率只有 61%，暴露出一堆「断言没真校验」的点——方向对了，但全量跑一次要 40 多分钟，CI 根本承受不起；
3. 想给变异测试定个「达标线」（比如杀死率 ≥80% 才放行），但不知道这条线该按类、按模块还是按风险等级来划，也不知道怎么让它只跑增量、控制时长。

【期望得到的答案形态】

• 变异测试在你们团队是「全量门禁」还是「抽样/增量 + 风险优先」？怎么控制单次时长到 CI 可接受范围（给具体配置或命令）；
• 「变异杀死率」的达标线怎么定、怎么按模块/风险分级，有没有踩过「为凑数字而改测试」的坑；
• 除了 PIT，大家还用过哪些工具（Java / Python / TS 各来一个），以及怎么把它和现有覆盖率报告一起呈现，让「断言有效性」变成一个可追踪的指标而不是玄学。