dupl可高效检测go项目中跨函数、跨文件的字面量重复代码块，建议阈值设为80行并过滤测试和vendor目录；staticcheck的st1016规则能识别硬编码字符串重复；ast解析适合深度定制化检测但性能较低，应定期手动运行而非纳入ci主流程。
用 gocyclo 和 dupl 快速发现重复逻辑
Go 项目里真正影响可维护性的重复，往往不是整段复制粘贴，而是相似的 if 链、结构体初始化、HTTP 错误处理模式。直接肉眼扫效率低，dupl 是专为这类场景设计的轻量工具——它按 token 序列比对，不依赖 AST，能抓到跨函数、跨文件的代码块重复。
安装后默认检测 150 行以上重复（太短容易误报），建议调低阈值：
go install github.com/mjibson/dupl@latest dupl -t 80 ./... | grep -v "vendor\|test"
dupl 输出格式是 file:line:column: length=XX，重点看 length 值：超过 20 行的重复块才值得重构；小于 10 行大概率是合理复用或模板代码。
-
dupl不识别语义等价（比如a == b和b == a算不同），只认字面一致 - 测试文件（
*_test.go）默认包含在扫描中，但多数测试重复是故意的，建议用grep -v过滤 - 如果项目用了 Go 1.22+ 的
type alias，dupl可能因类型名不同漏检，需人工补查
用 go vet -vettool=staticcheck 检测隐性重复模式
有些重复藏在“看似不同”的写法里，比如连续三处都用 fmt.Sprintf("%d", x) 转 int，而没用更安全的 strconv.Itoa(x)。staticcheck 的 SA1019 规则能标出过时 API 使用，但配合自定义检查能挖更深。
先安装并启用重复模式检测插件：
go install honnef.co/go/tools/cmd/staticcheck@latest staticcheck -checks 'ST1016' ./...
ST1016 会警告相同字符串字面量在多个地方硬编码（比如同一错误消息出现 3 次以上），这是典型重复信号。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别依赖
go vet自带规则——它不包含重复检测，必须显式指定staticcheck工具链 -
ST1016对日志中的占位符敏感（如"user %s not found"），但不会把"user A not found"和"user B not found"当重复，这点很关键 - 若项目大量使用
errors.New("xxx")，建议加-checks 'ST1028'检查错误构造一致性
写个最小化脚本跑 ast 分析做定制化重复识别
当 dupl 抓不到跨函数参数顺序不同但逻辑相同的重复（比如 foo(a, b) 和 bar(b, a)），就得下场写 AST 解析。核心思路：提取函数体 AST 节点的“骨架”，忽略变量名和字面量值。
下面这个脚本能识别相同结构的 if-else 链：
package main
import (
"go/ast"
"go/parser"
"go/token"
"log"
"path/filepath"
)
func main() {
fset := token.NewFileSet()
ast.Inspect(parser.ParseFile(fset, "main.go", nil, 0).(*ast.File), func(n ast.Node) {
if stmt, ok := n.(*ast.IfStmt); ok {
log.Printf("if block at %s", fset.Position(stmt.Pos()))
// 这里可提取 condition 类型、body 语句数、是否有 return 等特征
}
})
}
实际用时别解析单文件——用 filepath.Walk 扫整个 ./internal 目录，把每个 IfStmt 的 stmt.Cond 类型（*ast.BinaryExpr / *ast.CallExpr）和 stmt.Body.List 长度存成特征向量，再用 map[string][]string 聚类。
- AST 方案性能差，10 万行代码可能要 3 秒，别塞进 CI 主流程，适合定期手动跑
- 别试图比对完整 AST——节点位置、注释、空格都会导致不匹配，只取
reflect.TypeOf(n).Name()和子节点数量 - 如果项目用了泛型，
ast.CallExpr.Fun的类型名可能含[...]，需正则清洗后再哈希
CI 中集成重复检测要避开三个坑
很多团队把 dupl 塞进 GitHub Actions 后发现 PR 失败率高，问题不在工具本身，而在集成方式。
- 别用
dupl -t 50卡死阈值——新功能常带小段重复逻辑，应设为软警告：dupl -t 100 ./... | head -20，只报最严重的前 20 条 - 忽略生成代码：protobuf 生成的
*_pb.go文件必须排除，否则每次protoc更新都会触发误报 - 别让重复检测阻断 PR：它本质是技术债提示，应输出到评论区而非失败状态，用
gh issue comment推送结果更实用
重复检测最难的不是找到重复，而是判断“该不该动”。两处 HTTP 客户端错误重试逻辑长得一样，可能一个是历史遗留，一个是新写的——得看调用栈深度、panic 风险、是否在 hot path 上。工具只能标出候选，决策还得人来拍板。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
