它是唯一一项不需要人判断的质量检查：数字由工具算，判据写死在配置里，人和助手都没有解释空间。
工具报出超限的那个函数，能不能说清它同时在做的两件事？
说不清，先按误报处理；说得清就拆，拆完再跑到退出码 0。把阈值调高让当次通过，等于把这条判断从仓库里删掉。
一个函数里的分支越多，改动它时要同时记住的前提就越多。工具把这件事变成一个数字，超限即阻断，不给人讨价还价的余地。
一条计数差异要写清：不同语言的工具数法不同，直接把同一个数字搬过去会天天报警。TypeScript 侧取 20、其余语言取 10，不是漏写，是计数方式不同——理由写进决议，别让人以为是错别字。
工具报的不是「这段代码不好读」，是一条带位置、带数字、带阈值的结果。缺任何一项，都无法判断是不是误报。
backend/app/service/export.go:42
func buildRows
圈复杂度 17 （阈值 10）
语句数 68 （阈值 50）
规则 PLR0912 处理：提成一张分派表，或加一条带规则号的例外
要认的是这个形状：位置、函数名、数出来的值、阈值四样齐全。只有「复杂度过高」四个字而说不出是哪个数超了，这条报告没法复核。
处理：拆成 buildRows / buildRowsB / buildRowsC 拆分后 buildRows 圈复杂度 17（阈值 10） 数字没降 或 # nolint: PLR0912 没有规则号以外的理由 或 阈值 10 → 20 连真的超限一起放过
认它的办法：看数字有没有真的降下来。函数名变了而数字没变，是挪位置不是拆；例外里只有规则号没有理由，是关检查。三种写法都能让这一项变绿，没有一个碰到了分支本身。
场景：助手写的处理函数里先判会话与方法，再逐条校验字段，最后落库。合并请求一开，复杂度那一项变红，报出函数名与超限值。
下面几种是这条检查上最常出现的误报，按「改写法或加例外」处理，不是「把阈值调高」——调高会连真的超限一起放过。
| 现象 | 为什么是误报 | 怎么处理 |
|---|---|---|
| 一个多分支的分派结构报超限 | 每个分支各算 1，分支多不等于难懂 | 提成一张分派表；确认要保留就加一条带规则号的例外并写清理由 |
| 生成的代码报超限 | 不是人写的，读的人也不读它 | 按路径排除，不逐条加例外 |
| 测试文件里的用例表报超限 | 用例表本身就是数据，长度是它的内容 | 把表提成包级变量，或把测试目录排除在这条规则之外 |
| 只是一串提前返回却被报嵌套 | 该规则按 if 的复杂度累加，不是数层数 | 确认写法已经最简；只出现一次就接受，不调阈值 |
| 拆完函数后覆盖率数字下降 | 按行统计的分母变了 | 覆盖率按新增行看，不按文件总分看 |
这一节的边界：例外与排除都是「有条件地不看」。每加一条都要在合并请求里说明理由；不加说明直接加的例外，按不许改判据那一节退回。