beego 框架无需在 docker 容器中安装，应通过多阶段构建将依赖编译进静态二进制；运行阶段使用 alpine 或 scratch 镜像，不包含 go 环境、beego 源码或 bee 工具，配置和资源需手动指定路径。
Beego 框架本身不需要在 Docker 容器里“安装”——它只是 Go 项目的依赖，应该随项目一起编译进二进制文件；容器里只运行最终的可执行程序，不装框架、不装 bee 工具、不跑 go build。
真正要做的，是让构建阶段能拉到 Beego 依赖，而运行阶段干净、轻量、无 Go 环境。
Dockerfile 中不该出现 go get github.com/astaxie/beego
常见错误写法：
FROM golang:1.21 RUN go get github.com/astaxie/beego COPY . . RUN go build -o app . ENTRYPOINT ["./app"]
问题在于：
-
go get在模块模式（Go 1.16+ 默认）下已被弃用，会忽略go.mod，可能拉错版本 - 容器里残留了整个 Go 工具链和源码，镜像体积暴涨（常超 1GB）
- 运行时仍带
golang基础镜像，存在安全风险和冗余
正确做法是：分阶段构建（multi-stage build），仅在 builder 阶段用 Go 环境编译，运行阶段用 scratch 或 alpine。
使用 go mod + 多阶段构建才是标准流程
确保项目根目录有：
-
go.mod（含github.com/astaxie/beego v2或对应版本） -
main.go入口调用了beego.Run()
Dockerfile 示例：
FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o beego-app . <p>FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/beego-app . EXPOSE 8080 CMD ["./beego-app"]</p>
关键点：
-
go mod download必须在COPY .之前，利用 Docker 缓存加速构建 -
CGO_ENABLED=0确保生成静态二进制，避免运行时缺 libc -
alpine运行镜像不含 Go，也不需要beego源码或bee工具 - 不要手动
RUN go get，所有依赖由go mod管理
bee 工具完全不需要进生产容器
bee 是开发辅助工具（生成代码、热重载、打包），只在本地用：
-
bee new创建项目 -
bee run本地调试 -
bee pack打包发布（但 Docker 场景下更推荐直接go build）
如果硬要在容器里用 bee run（比如开发测试镜像），必须：
- 使用
golang镜像（不能用alpine或scratch） - 显式安装
bee：RUN go install github.com/beego/bee/v2@latest - 但这样镜像无法用于生产，且热重载在容器里不稳定，容易因挂载路径或 inotify 限制失败
Beego 的配置（如 conf/app.conf）、视图（views/）、静态资源（static/）必须在构建时或运行时显式挂载进容器。默认不会自动识别路径——尤其是当二进制被移到别的目录执行时，beego.AppPath 可能指向错误位置，得用 beego.SetViewsPath() 和 beego.LoadAppConfig() 手动指定绝对路径或基于 os.Executable() 推导。这点比纯 HTTP 服务更容易出错，也最容易被忽略。
