beego框架不应在kubernetes基础镜像中预安装，因其依赖通过go.mod声明并静态链接进二进制，运行时仅需编译好的可执行文件、配置文件（通过configmap/secret挂载）和正确workdir，严禁在生产镜像中安装bee工具或执行go get。
Beego 框架不能、也不应该在 Kubernetes 基础镜像中“预安装”。
Kubernetes 不关心你用什么框架，它只调度容器；而容器里不该有 Go 环境、bee 工具、go get 步骤或源码目录——这些全是构建阶段的事。
真正要做的，是让镜像里只有静态编译好的二进制文件，以及它运行所需的配置和资源文件。
为什么不能在基础镜像里装 Beego
Beego 是 Go 项目的依赖，不是系统级组件。你在 go.mod 里声明了 github.com/astaxie/beego，Go 编译器就会把它打包进最终的可执行文件。运行时不需要框架源码、不需要 bee、不依赖 GOPATH 或 GOROOT。
- Kubernetes 的 Pod 启动的是一个进程（比如
/app/server），不是开发环境 - 任何在
FROM golang:1.20镜像里执行go get github.com/astaxie/beego的操作，都属于冗余构建步骤，且会让镜像体积变大、攻击面增加 - 使用
scratch或alpine:latest作为运行镜像时，根本不存在go命令，更不可能“安装”框架
多阶段构建中 Beego 依赖怎么处理
Beego 依赖必须在构建阶段拉取并参与编译，但这个过程完全由 go build 自动完成，无需手动干预。
- 确保项目根目录下有
go.mod，且已执行过go mod tidy，其中包含github.com/astaxie/beego - 构建阶段使用
golang:1.20-alpine或类似镜像，只做go build -o /app/server . - 不要在 Dockerfile 中写
RUN go get github.com/astaxie/beego—— 这会绕过模块管理，导致版本不一致或构建失败 - 若用
bee生成项目，仅限本地开发；生成的main.go和routers/结构照常提交，但bee本身不进镜像
常见错误：把 bee 工具塞进生产镜像
有人会在 Dockerfile 里加 RUN go install github.com/beego/bee@latest，然后试图用 bee run 启动服务——这在 Kubernetes 中必然失败。
-
bee run是开发命令，依赖源码、热重载、watcher 进程，不适合容器环境 - Pod 中执行
bee run会报错：command not found（如果没装）或no Go files in（如果路径不对） - 即使侥幸跑起来，也会因监听不到信号、无法优雅退出、占用多余内存被 K8s 的 liveness probe 杀掉
- 正确启动方式永远是直接执行编译出的二进制：
CMD ["/app/server"]
Kubernetes 部署时 Beego 配置怎么加载
Beego 的配置（如 conf/app.conf）不能硬编码进镜像，得通过 ConfigMap 或 Secret 挂载。
- 构建镜像时不要
COPY conf/app.conf /app/conf/app.conf，除非是纯开发测试镜像 - 生产部署应挂载 ConfigMap 到
/app/conf/目录，并在代码中显式指定路径：beego.LoadAppConfig("ini", "/app/conf/app.conf") - 注意权限：Alpine 镜像中非 root 用户默认无法写入
/app/conf，挂载前确认目录可读 - Beego 默认从当前工作目录找
conf/app.conf，所以WORKDIR /app很关键
exec 起来的二进制。最容易被忽略的一点：很多人改完 app.conf 就直接 kubectl apply，却忘了 Beego 不会自动 reload 配置——它只在启动时读一次。
