Beego v2 依赖需按分支独立管理，每个分支必须单独执行 go mod init 和 go mod tidy，确保 go.sum 与当前 beego/v2 版本严格匹配，避免混用导致校验失败或 panic。
beego/v2 依赖必须按模块路径隔离安装
Beego v2 的依赖不是全局共享的，每个分支（即每个 go mod 项目）必须独立运行 go mod tidy。混用分支共用 go.sum 或复用 go.mod 是常见错误源头——尤其当 A 分支用的是 beego/v2@v2.3.4，B 分支升级到 v2.3.5，直接拷贝依赖会导致校验失败或 nil panic。
关键点在于：Beego v2 的导入路径是 github.com/beego/beego/v2，它被 Go Modules 视为一个独立模块，版本变更会直接影响 go.sum 哈希值。不同分支若没各自初始化模块、没各自拉取对应版本，bee run 启动时大概率报 missing go.sum entry 或 incompatible version。
多分支下 go mod init 和 go mod tidy 必须逐分支执行
不要在仓库根目录统一初始化，而应在每个功能分支的项目根目录（含 main.go 的那层）单独操作：
- 切换到分支后，先确认当前路径下没有
go.mod：若有且内容与本分支不符，删掉它 - 运行
go mod init myapp（模块名可自定义，但需保持唯一性，避免和其它分支冲突） - 再执行
go get -u github.com/beego/beego/v2和go get -u github.com/beego/bee/v2 - 最后跑一次
go mod tidy，确保go.sum与当前分支的依赖树完全匹配
注意：go mod tidy 不会自动降级已引入的高版本依赖——如果某分支需要锁定 v2.3.4，得显式写 go get github.com/beego/beego/v2@v2.3.4，再 tidy。
bee 工具本身不参与分支依赖管理，但它的行为受当前目录模块影响
bee 是一个 CLI 工具，二进制文件只有一份（通常在 $GOPATH/bin/bee），但它执行 bee run 时，会读取当前目录下的 go.mod 并据此编译。这意味着：
- 同一台机器上，
bee可以无缝切分支运行，只要每个分支的go.mod正确声明了beego/v2版本 - 若
bee run报undefined: web.Run，90% 是因为该分支的main.go还引用着旧路径github.com/astaxie/beego，而不是github.com/beego/beego/v2/server/web - 别在分支间共享
go.sum文件——哪怕只是复制粘贴，也容易因系统时间、Go 版本微小差异导致哈希不一致
CI/CD 流水线中要避免缓存污染
在 GitHub Actions、GitLab CI 等环境里，如果多个分支共用同一个构建缓存目录（比如 ~/.cache/go-build 或 GOBIN），可能引发静默错误：前一个分支的 bee 编译产物残留，干扰后一个分支的 go build 结果。
建议做法：
- 每次 CI 构建前加一步
go clean -modcache，强制清空模块缓存 - 用
go build -o ./bin/app .而非依赖bee build，减少工具链耦合 - 在
.gitignore中明确排除/bin、/pkg、go.sum（除非你有意 commit 它）——go.sum应该只在 PR 合并前由开发者本地生成并提交
真正容易被忽略的，是 go.sum 的“时效性”：它不是锁文件，而是校验快照；同一份 go.mod 在不同时间、不同网络环境下 go mod tidy 生成的 go.sum 可能不同。多分支协作时，必须让每个分支自己生成、自己验证、自己提交。
