golangci-lint 不解决依赖冲突，仅报错；真正定位修复需靠 go mod 工具链：用 go list -m all、go mod graph、go mod why 锁定冲突源头，确保 GO111MODULE=on、在 go.mod 根目录运行，并验证配置文件名与缩进正确。
golangci-lint 本身不解决依赖冲突，它只报错；真正要定位和修复模块兼容问题，得靠 go mod 工具链配合分析。你看到 SA1019、undefined 类型、或 no go files to analyze，大概率不是 linter 配置错了，而是 go.mod 根本没解析出一致的依赖树。
为什么 golangci-lint 会报 undefined 或 no go files to analyze
这不是 linter 的 bug，是它在告诉你：当前 module 的依赖状态不可用。
-
undefined: xxx—— 常见于 CI，本质是go list -deps失败，原因包括：GO111MODULE=off、go.mod缺失、replace指向了本地路径但 CI 没同步 -
no go files to analyze—— 你不在含go.mod的 module 根目录运行命令；Echo、Gin 等框架项目也一样，必须从go.mod所在目录执行golangci-lint run . - 即使
go build ./成功，golangci-lint仍可能失败——因为 linter 需要完整 AST，而某些//go:build注释（如 swag 生成的docs/doc.go）会让 parser 拒绝加载包
怎么用 go mod 定位冲突源头
别猜，用三行命令锁定谁在拉旧版：
-
go list -m all | grep 'github.com/sirupsen/logrus'—— 看当前 resolve 出的版本（比如 v1.8.1），确认是否是你想要的 -
go mod graph | grep 'logrus'—— 查哪些包直接依赖它，比如pkgA github.com/sirupsen/logrus@v1.8.1和pkgB github.com/sirupsen/logrus@v1.9.3同时存在 -
go mod why -m github.com/sirupsen/logrus—— 输出完整调用链，例如# github.com/sirupsen/logrus\nmain\n→ github.com/xxx/pkgA\n→ github.com/sirupsen/logrus，这才是真实依赖路径
replace + require 组合干预后为什么 still broken
replace 不是万能胶，它只接管当前 module 的解析，且极易被覆盖或忽略：
立即学习“go语言免费学习笔记（深入）”；
- 写了
replace A => B v1.9.3，但没跟一句go get A@v1.9.3→go.mod里不会新增或更新require A v1.9.3行，go mod tidy也不会补上 - 多个
replace形成循环：A replace B，B replace C，C replace A →go build直接 panic，“invalid replace loop” -
replace指向本地路径（如./local-fork），但该目录没go.mod或版本不匹配 →go mod download失败，linter 解析中断 - 用了
go mod vendor，但没跑go mod verify→vendor/modules.txt里的版本和go.sum对不上，linter 加载包时校验失败
CI 中 golangci-lint 报错但本地正常？先查这三项
环境漂移比代码问题更常见，优先验证基础一致性：
-
go env GO111MODULE—— CI 必须为on，否则go list返回空，linter 就认为“没包可查” -
go version—— CI 的 Go 版本不能低于本地，尤其注意 1.21+ 对泛型的 AST 解析更严格，旧版 linter 可能跳过某些检查 -
ls -l go.mod go.sum .golangci.yml—— 确认这三个文件都已git add并提交；.golangci.yml名字错一个字母（如.golangci.yaml）或缩进用了 Tab，linter 就静默失效
最常被忽略的一点：golangci-lint 的行为高度依赖 go list -m all 的输出结果。如果这个命令本身因模块不一致而返回错误，那后续所有检查都是空中楼阁——别急着调配置，先让 go mod graph 和 go mod why 跑通再说。
