Beego v2 是当前唯一可用的主线版本，v1 已彻底停更；安装需严格启用 GO111MODULE=on、配置 GOPROXY=https://goproxy.cn,direct，执行 go get -u github.com/beego/beego/v2 和 github.com/beego/bee/v2（顺序不可反），导入路径必须为 github.com/beego/beego/v2/server/web，启动用 web.Run()。
Beego v2 是当前唯一可用的主线版本，v1 已彻底停更；在多版本 Go 环境（如用 gvm、goenv 或手动切换 GOROOT）下安装失败，90% 是因为模块代理未对齐、GO111MODULE 状态不一致，或 go get 命令被旧版 Go 缓存干扰。
go get 命令必须加 -u 且指定 v2 路径
v2 的导入路径和二进制分发完全独立于 v1，不加 -u 会导致拉取到本地缓存的过期 commit（尤其在多次切换 Go 版本后），即使 GOPROXY 正常也无效。
- 必须执行这两条命令（顺序不能反）：
go get -u github.com/beego/beego/v2
go get -u github.com/beego/bee/v2
- 如果提示
no required module provides package，说明当前目录不在 Go Module 环境中：先运行go mod init myapp，再重试 - 禁止混用路径：
github.com/astaxie/beego（v1）和github.com/beego/beego/v2（v2）不能共存于同一go.mod
GO111MODULE 和 GOPROXY 必须显式启用
多版本 Go 下，不同版本默认的模块行为可能不同（例如 Go 1.15 默认 on，Go 1.12 默认 off），靠“默认开启”不可靠。
- 每次切换 Go 版本后，立即执行：
go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.cn,direct
- 验证是否生效：
go env GO111MODULE应输出on，go env GOPROXY应含goproxy.cn - 若仍报
golang.org/x/...类错误，不是 Beego 问题，而是代理未穿透：检查是否被 shell 配置（如.zshrc）里旧的export GOPROXY=覆盖
bee 二进制生成位置与 PATH 冲突最常见
不同 Go 版本调用 go install 时，GOBIN 解析逻辑可能受 GOPATH 或当前 shell 环境影响，导致 bee 生成在非预期路径。
- 执行
go get -u github.com/beego/bee/v2后，确认bee是否真在$GOBIN下：ls -l $GOBIN/bee*
（macOS/Linux）或dir %GOBIN%\bee*
（Windows） - 若不存在，手动构建：
cd $(go env GOPATH)/pkg/mod/github.com/beego/bee/v2@*/ && go build -o $GOBIN/bee .
- 务必把
$GOBIN加入PATH—— 不是$GOPATH/bin，也不是$GOROOT/bin，而是当前 Go 版本实际使用的GOBIN值
启动失败时优先检查 import 路径和入口函数
多版本环境容易残留旧项目模板，bee new 创建的项目若基于 v1 模板，会直接导致编译失败。
- 检查
main.go中 import 是否为：import "github.com/beego/beego/v2/server/web"
，而非github.com/astaxie/beego或github.com/beego/beego/v2（后者无Run()） - 启动必须用：
web.Run()
，不是beego.Run()（已移除）或web.Run("8080")（v2.3.5+ 不再接受字符串端口） - 控制器结构体继承必须写全：
type MainController struct { web.Controller }，漏掉web.会导致方法绑定失效
真正麻烦的点不在安装命令本身，而在于多版本 Go 会各自维护一套模块缓存（$GOMODCACHE）和 go.env 状态；一次 go clean -modcache 只清当前 Go 版本的缓存，切版本后得重来。建议每次切换 Go 版本后，顺手跑一遍 go env -w + go mod tidy，比事后 debug 快得多。
