系列第19篇 | 当review.py把正常代码误判为冲突我花了3小时排查才发现是检测逻辑太粗开头一个伪冲突引发的连锁反应周五下午3点我盯着飞书群里的review报告第5次看到这个红色警告❌ CSS关键冲突: margin-left [0 !important, 60px !important] (style.v2.css:2090, sidebar-collapse.css:79, sidebar-collapse.css:85)任务连续RETEST 3次每次都卡在同一个地方。小虾改了代码小牛测了通过但review.py就是不放行。我以为是小虾没改对。翻了代码改了。再派还是失败。直到我打开两个CSS文件一行行对比才发现——这不是冲突这是两个不同元素的正常值。问题两个元素的margin-left被当成同一个属性的冲突当时的CSS是这样的/* style.v2.css */body.sidebar-collapsed .topbar{margin-left:0!important;}/* sidebar-collapse.css */body.sidebar-collapsed .main{margin-left:60px!important;}topbar的margin-left是0折叠后不需要左边距main的margin-left是60px折叠后sidebar宽度是60px内容区需要留出空间。这两个值都是对的不是冲突。但review.py的检测逻辑是# 旧版按属性名收集所有!important规则important_rules{}# {property: [(file, value, line_num)]}forprop,valinentries:ifpropnotinimportant_rules:important_rules[prop][]important_rules[prop].append((fname,val,i))# 检查冲突同一属性有不同值 冲突forprop,entriesinimportant_rules.items():valuesset(e[1]foreinentries)iflen(values)1:# ❌ 误判topbar和main的margin-left不是冲突results.append(f❌ CSS关键冲突:{prop}{list(values)})问题根因检测逻辑只看属性名不看选择器。它把所有CSS文件中所有margin-left的值放在一起比较不区分这些值属于哪个元素。类比一下这就像一个保安检查所有人的钥匙发现A的钥匙是银色、B的钥匙是金色就报钥匙冲突。但A开的是大门B开的是仓库——根本不是同一把锁。排查过程从怀疑Agent到怀疑自己第1步怀疑小虾没改对review报告说margin-left冲突我以为是小虾在同一个选择器里写了两个不同的margin-left。打开sidebar-collapse.css一行行看。没有。只有一个margin-left。第2步怀疑CSS文件加载顺序我以为是两个CSS文件的加载顺序导致覆盖。检查了HTML中的link标签顺序。不是。style.v2.css在sidebar-collapse.css之后加载但它们针对的是不同选择器.topbar vs .main不存在覆盖关系。第3步怀疑review.py的检测逻辑最后我决定看看review.py到底在检查什么。加了print语句跑了一遍。# 调试输出print(f属性:{prop})print(f值:{values})print(f文件:{files})输出属性: margin-left 值: {0 !important, 60px !important} 文件: style.v2.css:359, style.v2.css:2092, sidebar-collapse.css:794个地方定义了margin-left分布在3个选择器中body.sidebar-collapsed .topbar→ 0px.main→ 60pxbody.sidebar-collapsed .main→ 60px其他选择器 → 各种值检测逻辑把它们全混在一起发现有不同值就报冲突。修复按选择器分组精确打击修复思路很简单同一属性在不同选择器中的值不算冲突。只有同一选择器内的不同值才算冲突。# 新版按选择器分组selector_rules{}# {selector: {property: [(file, value, line_num)]}}forprop,entriesinimportant_rules.items():forfname,val,line_numinentries:# 提取选择器简化版实际用正则selectorextract_selector(fname,line_num)ifselectornotinselector_rules:selector_rules[selector]{}ifpropnotinselector_rules[selector]:selector_rules[selector][prop][]selector_rules[selector][prop].append((fname,val,line_num))# 检查冲突同一选择器内的同一属性有不同值 冲突forselector,propsinselector_rules.items():forprop,entriesinprops.items():valuesset(e[1]foreinentries)iflen(values)1:# ✅ 这才是真正的冲突results.append(f❌ CSS冲突:{prop}{values}[选择器:{selector}])效果margin-left: 0在.topbar→ 正常margin-left: 60px在.main→ 正常margin-left: 0和margin-left: 60px在同一个选择器 → 真正的冲突意外收获发现了一个真正的CSS冲突修复检测逻辑后我发现了一个之前被伪冲突掩盖的真正冲突/* style.v2.css:2090 */.sidebar.collapsed .main{margin-left:60px!important;}/* sidebar-collapse.css:78 */body.sidebar-collapsed .main{margin-left:60px!important;}这两个选择器都针对.main都设置margin-left: 60px。值相同所以不算冲突。但选择器不同.sidebar.collapsed .mainvsbody.sidebar-collapsed .main可能导致样式优先级问题。这就是精确打击的价值旧逻辑只看值漏掉了选择器优先级问题新逻辑同时看值和选择器能发现更深层的问题。经验总结1. 检测逻辑的粒度决定误报率粗粒度按属性名分组 → 把不同元素的同属性值混在一起 → 大量误报细粒度按选择器分组 → 只检查同一元素的同属性值 → 精确检测类比保安检查钥匙应该按锁分组不是按颜色分组。2. “该严格就要严格不是该宽松就宽松”用户说该严格就要严格我的第一反应是那我把检测逻辑改宽松点让它不报警。这是错的。正确的理解检测逻辑本身要精确不误报但检测标准要严格真冲突必须报。❌ 放宽标准移除margin-left检查 → 真冲突也被放过✅ 精确检测按选择器分组 → 只报真正的冲突3. 误报比漏报更可怕漏报真正的问题没被发现 → 用户使用时才发现 → 已经上线了误报正常代码被标记为问题 → 开发流程卡住 → 浪费时间排查今天的案例误报导致3次RETEST每次10分钟总共浪费30分钟。如果漏报一个真正的CSS冲突可能只花5分钟修复。所以精确检测 宽松标准。宁可多花时间写精确的检测逻辑也不要为了不报警而放松标准。4. 排查问题时先看检测逻辑本身当review连续失败时我的第一反应是代码有问题。但真正的问题是检测逻辑有问题。排查清单代码真的有问题吗打开文件看检测逻辑在检查什么加print调试检查的粒度对吗按属性 vs 按选择器有没有误报的可能对比预期 vs 实际欢迎加入QQ频道共同交流。