问题文件
internal/agent/hardcoded_host_check.go — 行 76-93 (delta 过滤), 行 183-188 (Go finding 构建)
问题描述
checkHardcodedHost 的 delta-aware 过滤逻辑对 Go AST 检测结果使用了包含位置信息(文件名:行号:列号)的字符串作为去重 key。当用户编辑了 ListenAndServe 调用上方的代码(添加注释、import、空行等),该调用的行号会变化,导致新 finding 的位置字符串与旧 finding 不同。delta 过滤使用精确字符串匹配,位置不同导致匹配失败,已有的 hardcoded host 被重新报告为"新引入的"。
JS/TS 检测不受此问题影响,因为其 finding 字符串不包含位置信息。
触发场景
- 文件已有
http.ListenAndServe(":8080", nil) 在第 4 行
- Agent 在第 2 行上方添加了 3 行注释或 import
ListenAndServe 移至第 8 行
- 旧 finding:
...at server.go:4:2 uses a hardcoded bind address...
- 新 finding:
...at server.go:8:2 uses a hardcoded bind address...
- 字符串不匹配 → delta 过滤失败 → 重新报告为"新"的 hardcoded host
预期行为 vs 实际行为
预期: ListenAndServe 调用内容未改变时,不应在 delta 中报告为新问题。
实际: 任何改变行号的编辑都会导致同一个 hardcoded host 被重新报告。
根本原因
- 行 183:
posStr := fset.Position(call.Pos()).String() — 获取 filename:line:col 位置字符串
- 行 184-188: finding 字符串中嵌入
posStr
- 行 88-92: delta 过滤使用 finding 字符串完全匹配
对比 JS/TS(行 267-269):finding 字符串仅为 .listen(8080) uses a hardcoded port...,不含位置信息,delta 过滤正常。
修复建议
方案 B(推荐): 为 delta 比较使用不含位置信息的 fingerprint(fnName + addr),在用户面向的消息中保留完整位置信息:
type hostFinding struct {
msg string // 用户可见消息(含位置)
fingerprint string // delta key: fnName + ":" + addr(不含位置)
}
严重程度
Medium — 纯噪声问题,不影响安全性或代码正确性。但在典型 agent 工作流中频率极高(添加注释/import/文档时触发),会削弱用户对检测器的信任。
验证方式
独立 subagent 编写了 Go 测试,直接调用 checkHardcodedHost 验证:
- 旧内容中
ListenAndServe 在第 4 行
- 新内容中移至第 8 行(上方添加 3 行注释)
checkHardcodedHost 返回 1 个 delta 警告(预期为 0)
- 测试输出确认:
BUG CONFIRMED: expected 0 delta warnings, got 1
问题文件
internal/agent/hardcoded_host_check.go— 行 76-93 (delta 过滤), 行 183-188 (Go finding 构建)问题描述
checkHardcodedHost的 delta-aware 过滤逻辑对 Go AST 检测结果使用了包含位置信息(文件名:行号:列号)的字符串作为去重 key。当用户编辑了ListenAndServe调用上方的代码(添加注释、import、空行等),该调用的行号会变化,导致新 finding 的位置字符串与旧 finding 不同。delta 过滤使用精确字符串匹配,位置不同导致匹配失败,已有的 hardcoded host 被重新报告为"新引入的"。JS/TS 检测不受此问题影响,因为其 finding 字符串不包含位置信息。
触发场景
http.ListenAndServe(":8080", nil)在第 4 行ListenAndServe移至第 8 行...at server.go:4:2 uses a hardcoded bind address......at server.go:8:2 uses a hardcoded bind address...预期行为 vs 实际行为
预期:
ListenAndServe调用内容未改变时,不应在 delta 中报告为新问题。实际: 任何改变行号的编辑都会导致同一个 hardcoded host 被重新报告。
根本原因
posStr := fset.Position(call.Pos()).String()— 获取filename:line:col位置字符串posStr对比 JS/TS(行 267-269):finding 字符串仅为
.listen(8080) uses a hardcoded port...,不含位置信息,delta 过滤正常。修复建议
方案 B(推荐): 为 delta 比较使用不含位置信息的 fingerprint(fnName + addr),在用户面向的消息中保留完整位置信息:
严重程度
Medium — 纯噪声问题,不影响安全性或代码正确性。但在典型 agent 工作流中频率极高(添加注释/import/文档时触发),会削弱用户对检测器的信任。
验证方式
独立 subagent 编写了 Go 测试,直接调用
checkHardcodedHost验证:ListenAndServe在第 4 行checkHardcodedHost返回 1 个 delta 警告(预期为 0)BUG CONFIRMED: expected 0 delta warnings, got 1