圈复杂度超10需介入，超15表明逻辑难穷举；应通过静态分析定位高危嵌套，依四类模式（校验/映射/组合/流程型）分别采用卫语句、表驱动、策略键生成、步骤提取等重构手法，并遵守禁增嵌套、if总数≤4、命名语义化、测试全覆盖等硬约束。
直接看圈复杂度数值本身意义不大，关键是要识别出哪些 if 嵌套正在把控制流、业务判断和副作用混在一起——这才是超标背后的真实风险。通常方法圈复杂度超过 10 就该介入，超过 15 往往意味着逻辑已难以靠人脑穷举路径。
定位高危嵌套的实操步骤
先用静态分析工具（如 SonarQube 或 IntelliJ 的 Code Metrics）跑一次全量扫描，重点关注： • 方法内 if/else-if/else 数量 ≥ 5 的函数； • 嵌套深度 ≥ 3 层 的代码块（IDE 通常会标灰或加提示）； • 同一方法中出现 多个非空校验 + 多个状态判断 + 多个值匹配 混合的场景（比如 user != null && user.isActive() && "ADMIN".equals(user.getRole().getName())）； • 单元测试覆盖时，发现某方法需要写 8+ 个 case 才能勉强打到 80% 分支覆盖率。
四类典型嵌套模式及对应重构手法
1. 校验型嵌套（如参数/对象/状态前置检查） → 改用卫语句（Guard Clauses）：每个条件单独一行 + 提前 return，不包大括号，保持主干左对齐。 → 避免把 null 检查、active 判断、role 存在性、role 名字匹配塞进一个 if 条件里。
2. 映射型嵌套（如字符串/枚举 → 行为）
→ 改用表驱动法：用 Map
3. 组合型嵌套（如租户类型 × 资源部门 × 操作类型 = 12 种路径） → 不硬写 if-else if，改用策略键生成器（如 key = tenantType + "_" + dept + "_" + op），再查表执行； → 或拆成三层职责：先归一化输入 → 再路由到子策略 → 最后由具体策略执行原子操作。
4. 流程型嵌套（如“查A→不存在则插A→成功再查B→失败则回滚”）
→ 提取每步为独立方法（ensureAExists()、insertAIfMissing()、verifyBAfterA()）；
→ 主流程改用异常驱动或 Result
重构过程中的硬性约束
• 禁止新增嵌套：任何 PR 中出现新 if 块导致嵌套加深，CI 直接拒绝； • 单方法 if-else 总数 ≤ 4（含 else-if），超限必须拆； • 所有提取出的新方法需有明确业务语义名（如 validateOrderEligibility()，而非 checkSomething()）； • 每次重构后必须补全对应单元测试，覆盖原逻辑所有分支路径，且测试方法名与被测逻辑一致（如 testWhenUserIsNull_thenReturnsEarly）。
