Beego项目依赖锁定需分vendor与module两种模式：旧项目禁用Go Modules时用govendor管理vendor目录；新项目有go.mod则用go mod vendor生成并配合-mod=vendor使用，且依赖go.mod+go.sum才是可靠锁定。
Beego 项目用 vendor 锁定依赖，只在明确禁用 Go Modules 的旧项目中可行；若项目已有 go.mod，go mod vendor 生成的 vendor/ 本质是 module 模式的产物，且需配合 -mod=vendor 才真正生效——不是放了 vendor 目录就自动锁定。
确认当前是否走 vendor 路径
Go 不会因为存在 vendor/ 就自动优先读它。必须满足两个前提：
-
GO111MODULE环境变量为off或auto（不能是on） -
go list -f '{{.Dir}}' .输出路径不含/pkg/mod/，否则说明仍在走 module 模式
运行 go env GO111MODULE 和 go list -f '{{.Deps}}' . | head -n3 可快速验证。如果输出里出现类似 github.com/beego/beego/v2@v2.3.5 这种带版本号的路径，说明没切到 vendor 模式。
纯 vendor 模式下初始化 vendor 目录
不依赖 go.mod，只靠 GOPATH 和传统工作区结构（$GOPATH/src/your/project），推荐用 govendor 工具：
- 安装：
go get github.com/kardianos/govendor - 进入项目根目录（确保在
$GOPATH/src/xxx下），执行：govendor init（生成vendor/vendor.json） - 拉取所有外部依赖：
govendor add +external - 指定版本拉取 Beego v2：
govendor fetch github.com/beego/beego/v2@v2.3.5
注意：govendor 不识别 go.mod，所以项目里不能有 go.mod 文件，否则会报错或行为异常。
module 模式下生成并使用 vendor 目录
如果你的项目已有 go.mod（绝大多数新项目如此），vendor 是辅助手段，不是主流程：
- 先确保
go.mod中声明了 Beego v2：require github.com/beego/beego/v2 v2.3.5 - 运行：
go mod vendor（生成vendor/和vendor/modules.txt） - 编译时强制走 vendor：
go build -mod=vendor - 测试时也加标志：
go test -mod=vendor ./...
⚠️ 关键点：go mod vendor 不会修改 go.mod 或 go.sum，它只是把当前 go.mod 解析出的依赖快照复制进 vendor/；若后续改了 go.mod，必须重新执行该命令。
常见失效场景和验证方式
即使有 vendor/ 目录，构建仍可能绕过它去拉远程包：
- 忘记加
-mod=vendor标志 → 构建时仍走 proxy 或本地缓存 -
vendor/modules.txt缺失或格式错误 →go build -mod=vendor会直接报错no modules found - Beego 导入路径写错，比如用了
github.com/astaxie/beego（v1）而 vendor 里只有 v2 → 编译失败，提示cannot find package - 想验证是否真从 vendor 读：删掉
$GOPATH/pkg/mod/cache，再跑go build -mod=vendor，不报网络错误即成功
真正可靠的锁定，靠的是 go.mod + go.sum；vendor/ 只是它的可选镜像，且维护成本高、易被忽略更新——除非 CI/CD 环境明确禁止外网访问，否则没必要强依赖它。
