beego项目在jenkins上ci的关键是构建稳定、测试可追溯、失败可定位；需显式管理go环境与beego依赖，禁用端口监听与日志阻塞，按go习惯精简stage，并通过环境变量控制runmode。
Beego 项目在 Jenkins 上做持续集成，关键不是“能不能跑”，而是“怎么让构建稳定、测试可追溯、失败能定位”。Jenkins 本身不认 Beego，它只认 go 命令、go test 输出和退出码。只要 Go 环境配对、依赖能拉全、测试用例写得规范，Beego 项目 CI 就是标准 Go 项目 CI。
Go 环境与 Beego 依赖必须显式声明
Beego 是 Go 第三方框架，Jenkins agent 默认不带 bee 工具，也不自动 go get 项目依赖。直接跑 go build 很可能失败，报错类似 cannot find package "github.com/beego/beego/v2" 或 command not found: bee。
实操建议：
- 在 Jenkinsfile 或构建步骤开头，明确执行
go mod download（推荐）或go get -u github.com/beego/beego/v2，确保模块缓存完整 - 避免用
bee build—— 它是开发辅助工具，非标准构建入口；CI 中统一走go build -o app . - 若项目仍用
GO111MODULE=off+gopkg.in旧路径，需在构建前设环境变量：env GO111MODULE=off - Jenkins 全局工具配置里，
GOROOT和GOPATH必须与构建脚本中预期一致；推荐使用 Jenkins 的Go Tool插件管理多版本 Go
Beego 测试必须禁用监听端口与日志阻塞
Beego 默认启动时会监听 :8080，且 beego.Run() 是阻塞调用。如果 Jenkins 构建步骤里误执行了 go run main.go 或未隔离测试环境，构建会卡住、超时，或报错 listen tcp :8080: bind: address already in use。
实操建议：
- 单元测试文件（如
models_test.go）中，用beego.TestBeegoInit("test")初始化 Beego，而非beego.Run() - 所有测试函数前加
func TestXxx(t *testing.T) { beego.BConfig.RunMode = "test" }，强制进入测试模式，跳过 HTTP 启动 - 避免在
TestMain里调用beego.Run()；如有必要，用defer beego.BeeApp.Shutdown()清理 - Jenkins 的
go test命令建议加参数：go test -v -timeout 60s ./... -coverprofile=coverage.out
Jenkinsfile 中 Beego 项目的 stage 划分要按 Go 习惯，别套 Java 模式
很多团队照搬 Maven 的 clean → compile → test → package 阶段划分，但 Go 没有 “编译产物目录” 概念，go build 直出二进制，go test 不生成 class 文件。硬拆阶段反而增加维护成本、掩盖真实问题。
实操建议：
- 精简为三个 stage：
Checkout（拉代码）、Build & Test（go build+go test一起跑，失败即停）、Archive（用archiveArtifacts保存app二进制和coverage.out） - 不要在
Build & Test阶段分两次调sh：一次go build，一次go test—— 这会导致测试通过但构建失败时，二进制没生成却进了归档 - Beego 项目常含
conf/app.conf，CI 中应注入环境变量替代文件读取，例如：sh 'APP_ENV=test go test ./...'，并在代码中用beego.AppConfig.String("app::env")读取
最容易被忽略的是 Beego 的 RunMode 与 AppConfig 加载顺序 —— Jenkins 构建时若没显式设 APP_ENV 或 runmode，Beego 会 fallback 到 dev 模式，可能触发数据库连接、邮件发送等非测试行为，导致构建不稳定。这点不写死在 Jenkinsfile 或 go test 参数里，光靠配置文件永远不可靠。
