dependabot 不支持 go modules 的语义化版本解析，仅按字典序匹配 tags，忽略 replace/exclude、不处理 go.sum 和间接依赖、不识别 go.work，需手动验证构建与版本一致性。
Dependabot 不支持 Go modules 的直接语义化版本解析
Dependabot 默认对 go.mod 文件的处理是“扫描依赖行 + 匹配 GitHub 仓库”，它**不解析 go.sum、不理解 replace 或 exclude、也不按 semver 自动判断可升级范围**。这意味着你看到的 PR 可能升级到一个根本无法构建的版本，或者漏掉实际可用的补丁更新。
- 它只看
require行里的模块路径和版本字符串（如github.com/sirupsen/logrus v1.9.0），然后去对应 repo 的 tags 列表里找“字典序最新”的 tag —— 对v1.9.0来说，v1.9.10会被认为比v1.9.2新，但v1.10.0反而会被忽略（因为"v1.10.0" 字符串比较） - 如果你用的是
latest或master这类非语义化引用，Dependabot 会拒绝创建 PR（报错invalid version "latest"） - 私有模块（如
git.company.com/internal/pkg）默认不被扫描，除非你在.dependabot/config.yml中显式配置directory和package-ecosystem: gomod
必须手动写 .dependabot/config.yml 才能生效
GitHub UI 里的 Dependabot 设置页面对 Go 项目基本无效 —— 它不会自动识别 go.mod，也不会生成合理配置。不放配置文件，Dependabot 就当没这个项目。
- 最小可用配置长这样：
version: 2 updates: - package-ecosystem: "gomod" directory: "/" schedule: interval: "weekly" -
directory必须写对：多 module 项目（比如根目录是cmd/，api/，go.mod在各子目录）要为每个go.mod单独写一条updates，且directory设为对应路径（如"/api"） - 别加
open-pull-requests-limit：Go 依赖经常一升就是一串传递依赖，设成 10 很容易卡住后续更新
升级失败常见于 replace 和 indirect 依赖冲突
Dependabot 生成的 PR 经常在 CI 里失败，不是因为版本本身有问题，而是它没考虑你本地的 replace 规则或间接依赖约束。
- 例如你在
go.mod里写了replace github.com/gorilla/mux => ./vendor/mux，Dependabot 仍会尝试把线上最新版v1.8.0写进 require 行，导致go build报require github.com/gorilla/mux: version "v1.8.0" invalid: github.com/gorilla/mux@v1.8.0: reading https://proxy.golang.org/github.com/gorilla/mux/@v/v1.8.0.mod: 410 Gone -
// indirect标记的依赖，Dependabot 默认不升级 —— 但它可能正是一些安全漏洞的源头（比如golang.org/x/crypto被golang.org/x/net间接引入），得靠allow规则放开：allow: - dependency-name: "golang.org/x/crypto"
- CI 失败时先跑
go mod tidy && go build ./...本地复现，再看是不是go.sum校验失败或 proxy 返回 404 —— 这类问题只能手动改 PR，Dependabot 不会重试
Go 1.21+ 的 go.work 文件目前不被 Dependabot 识别
如果你用 go work use ./api ./cli 管理多模块工作区，Dependabot 完全无视 go.work，也不会扫描其中列出的目录。它只认单个 go.mod 文件。
- 后果是：主工作区升级了，子模块没跟上，
go run或go test直接报no required module provides package - 临时解法：在
.dependabot/config.yml里为每个go.mod显式声明一条updates，哪怕它们都在同一个 repo 下 - 没有自动同步机制 —— 你得自己记住哪些模块该一起升，否则很快出现版本漂移
Dependabot 对 Go 的支持始终卡在“能扫、能提、但不理解模块关系”这一步。最麻烦的从来不是配置怎么写，而是每次 PR 合并前，你都得手动验证 go build、go test、go list -m all 输出，以及确认 replace 和 exclude 是否还生效。
