indirect 标记表示该模块未被当前模块直接 require，而是通过其他依赖间接引入；若代码实际使用了它，应手动 go get 指定版本使其变为 direct 依赖。
go mod why 显示 indirect 却实际被引用
模块里出现 indirect 标记，不代表它没被用——只是没在当前模块的 go.mod 中被直接 require。常见于：你引入了 A 包，A 又依赖 B，而你自己也写了 import _ "B" 或调用了 B 的导出符号，但没显式 require B。
这会导致升级 A 后 B 的版本意外变更（比如 A 新版换掉了 B），运行时 panic 或编译失败。
- 用
go mod graph | grep查谁拉进了这个间接包，例如：go mod graph | grep github.com/sirupsen/logrus - 如果确认自己代码确实用了它，就手动
go get github.com/sirupsen/logrus@v1.9.3，让它变成 direct 依赖 - 注意
go mod tidy不会自动把 indirect 提升为 direct，除非 import 路径出现在 .go 文件里且未被任何其他 direct 依赖覆盖
replace 和 exclude 同时存在时行为不可靠
replace 是开发期临时替换路径或版本，exclude 是彻底屏蔽某个版本；两者混用会让 go build 和 go list -m all 输出不一致，CI 构建可能突然失败。
典型错误场景：本地用 replace 指向 fork 分支调试，CI 环境没同步该 replace，又忘了 exclude 掉原版冲突版本，结果拉下旧版导致类型不匹配。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用
replace+go mod edit -dropreplace控制作用域，避免长期写死在go.mod里 -
exclude只应在明确知道某版本有严重 bug 且无法升级上游时使用，且必须配合go mod verify确认没漏掉间接依赖中的同名包 - CI 中建议加检查：
go list -m all | grep 'your-broken-package@vX.Y.Z'，命中即报错
go list -m -u all 报 “can't load package” 但模块明明能编译
这个命令本质是尝试加载所有模块元信息，不是编译检查。报错常因某个依赖的 go.mod 文件语法错误、引用了不存在的版本、或其 require 中有平台特定条件（如 // +build ignore 错误放在了 go.mod 附近）。
它不影响构建，但会掩盖真正需要升级的过期包。
- 先跑
go list -m -f '{{.Path}} {{.Version}}' all，过滤出你关心的包，绕过解析失败的模块 - 对疑似问题包单独查：
go list -m -u github.com/gorilla/mux，看是否只它报错 - 若该包是你间接依赖，且你不需要它的新特性，可暂时
exclude掉对应版本，而不是硬扛解析失败
vendor 目录里有包却 still get “cannot find module”
启用 vendor 后，go build 默认只读 vendor，但某些情况仍会回源：GO111MODULE=on 且当前目录不在 module root 下、或执行了 go get 命令、或 go test 时用了 -mod=readonly 以外的模式。
最隐蔽的问题是：vendor/ 下文件权限不对（比如从 Windows 复制过来缺少执行位），或 git submodule 未更新导致 vendor 内容不全。
- 确认是否真在 module root：
go env GOMOD输出应为xxx/go.mod，不是no go.mod - 强制走 vendor：
go build -mod=vendor，而非依赖默认行为 - 校验 vendor 完整性：
go mod vendor -v看有没有 skip 或 error，尤其注意 “no matching versions” 类提示
依赖图不是静态快照，而是构建时按需解析的结果；同一行 go build 命令，在不同 GOPATH、GO111MODULE、甚至不同 shell 环境变量下，可能拉取完全不同的版本组合。
