beego多版本发布关键在于隔离构建上下文、依赖路径与运行时环境，而非框架本身支持；v1用github.com/astaxie/beego，v2拆分为github.com/beego/beego/v2等子模块，需严格区分导入路径、go.mod配置及基础镜像版本。
Beego 项目在 DevOps 流水线中做多版本发布，关键不是框架本身支持“多版本”，而是你能否隔离 v1 和 v2 的构建上下文、依赖路径与运行时环境。 否则很容易出现 go: inconsistent vendoring、undefined: beego.BConfig 或部署后路由 404 等问题。
Beego v1 与 v2 的导入路径和模块边界必须严格区分
v1 使用 github.com/astaxie/beego，所有功能（日志、ORM、Session）都塞在同一个包里；v2 拆成 github.com/beego/beego/v2 + 子模块如 github.com/beego/server/v2、github.com/beego/core/v2/logs。这意味着：
- 同一仓库不能混用 v1 和 v2 的 import 路径，否则
go build会报imported and not used或符号冲突 - CI/CD 流水线中若共用一个
go.mod，必须用replace显式重定向，例如：replace github.com/astaxie/beego => github.com/beego/beego/v2 v2.3.4
- v2 的
bee工具（github.com/beego/bee/v2）不兼容 v1 项目结构，bee run会直接 panic
流水线中如何安全地并行构建多个 Beego 版本
常见错误是让不同分支共享同一个构建缓存或 GOPATH，导致 go mod download 拿错版本。正确做法是按版本隔离构建环境：
- 在 GitLab CI / GitHub Actions 中，为 v1 分支设置
GO111MODULE=on+GOPROXY=https://goproxy.cn,direct，并在go.mod顶部固定require github.com/astaxie/beego v1.12.3 - v2 分支启用
GOFLAGS=-mod=readonly，防止意外修改go.sum；同时用go list -m all | grep beego在构建前校验实际加载的模块版本 - 避免复用 Docker 构建镜像层：v1 项目用
golang:1.19-alpine基础镜像，v2 项目用golang:1.21-alpine，防止go tool compile版本不兼容
多版本发布时最容易被忽略的配置点
Beego 自身不管理部署目标，但它的配置加载机制会让 DevOps 流程“静默失败”：
-
beego.BConfig.AppName和beego.BConfig.RunMode默认从conf/app.conf读取，而该文件常被 .gitignore 排除——CI 流水线中若没显式注入配置，服务会 fallback 到开发模式，监听127.0.0.1:8080而非0.0.0.0:8080，导致容器内无法访问 - v2 的日志模块默认不写文件，除非手动调用
logs.SetLogger(logs.AdapterFile, `{"filename":"logs/app.log"}`)；若监控脚本只 tailapp.log，就会漏掉启动期 panic - 使用
bee pack打包时，v1 输出的是myproject.tar.gz，v2 默认输出myproject_v2.tar.gz——如果部署脚本硬编码了解压路径，会解错包
真正卡住多版本发布的，往往不是 Beego 功能差异，而是构建阶段对 go.mod 解析逻辑的理解偏差、配置文件的环境感知缺失，以及打包产物命名约定的隐式耦合。这些地方不写死、不验证，上线时就只能靠 curl -v 一层层试。
