go mod tidy 删除未被 import 的依赖是正常清理行为，只保留代码中实际引用的包；未 import 的依赖即使手动添加也会被移除。
go mod tidy 为什么删掉了我刚加的依赖？
它不是“删”，是清理——go mod tidy 只保留当前代码中 实际 import 的包，没被 import 的，哪怕你手动写进 go.mod 或执行过 go get，也会被移除。
常见错误现象：go.mod 里明明有 github.com/sirupsen/logrus v1.9.3，但运行 go mod tidy 后就没了；或者 CI 构建失败，报错 cannot find package "github.com/xxx"。
- 检查是否真有
import "github.com/sirupsen/logrus"（注意拼写、大小写、路径层级） - 确认 import 不在被
// +build ignore或条件编译屏蔽的文件里 - 如果只是测试用，把 import 放到
xxx_test.go文件，并确保该文件名符合 Go 测试命名规范（否则tidy会忽略） - 临时保留但不 import？不行——
go mod tidy不支持“预留依赖”，得用go get+ 注释说明，或改用replace配置兜底
CI 中 go mod tidy 报 checksum mismatch 怎么办？
这是模块校验失败，核心原因：你本地 go.sum 记录的哈希值，和远程代理（如 proxy.golang.org）返回的模块内容不一致。可能因为模块被重发、镜像源缓存污染、或有人恶意篡改了 tag。
使用场景：GitHub Actions / GitLab CI 执行 go mod tidy 突然失败，错误信息类似：verifying github.com/xxx@v1.2.3: checksum mismatch
立即学习“go语言免费学习笔记（深入）”；
- 先运行
go clean -modcache清掉本地模块缓存，再重试 - 检查
GO_PROXY是否指向可信源（推荐https://proxy.golang.org,direct），避免用不可控的私有镜像 - 若确认是上游问题（比如作者强制推送了同 tag 新版），可临时用
go mod download拉取并更新go.sum，但需同步通知团队 - 严禁加
-dirty或关校验——这等于放弃完整性保护
go mod tidy 在 vendor 模式下还必要吗？
必要，而且更关键。启用 vendor 后，go mod tidy 不仅同步 go.mod/go.sum，还会确保 vendor/ 目录与模块声明完全一致——少一个包、多一个包、版本错位，都会导致构建行为不一致。
性能影响：开启 GOFLAGS="-mod=vendor" 后，go build 会跳过网络请求，但 go mod tidy 本身仍需联网校验（除非配 GO_PROXY=direct 并确保所有依赖已存在本地缓存）
- 每次提交前必须跑一遍
go mod tidy && go mod vendor，不能只做后者 -
vendor/不应手动增删文件——所有变更必须由go mod vendor生成 - Git 忽略
vendor/？不行。持续交付要求vendor/提交入库，否则不同环境行为不可控
多个 main 包共存时 go mod tidy 容易漏依赖
Go 模块按 go.mod 所在目录为根，但 go mod tidy 默认只扫描当前目录下的所有 .go 文件。如果你有多个 cmd/xxx/main.go，而当前工作目录不在模块根，或某些 main 包被放在子模块里，tidy 就看不到它们的 import。
典型表现：本地 go run cmd/a/main.go 没问题，但 CI 构建 cmd/b/main.go 时报 undefined: xxx，查发现对应依赖根本没进 go.mod
- 始终在模块根目录（即含
go.mod的目录）下运行go mod tidy - 确保所有
main包路径都被go list ./...扫描到；如有特殊布局（如apps/*/main.go），显式执行go mod tidy -v ./apps/... - 避免用
go mod edit -require手动加依赖——它绕过 import 检查，后续 tidy 会删掉
模块边界模糊、main 分散、vendor 和 proxy 配置混用——这些地方一松动，go mod tidy 就从维护者变成“甩锅者”。它不聪明，只机械执行规则；你得比它更清楚哪行 import 被谁用了、在哪编译、对谁生效。
