beego项目应采用多阶段构建：第一阶段用golang:1.21-alpine编译为单体二进制，第二阶段仅将二进制、prod模式配置、static/views资源复制至alpine:3.20镜像，显式设置路径与环境变量，禁用dev模式以保障安全与稳定性。
Beego 项目直接用 go build 编译成单体二进制后扔进 Alpine 镜像运行，是最轻、最稳、最接近生产环境的方案。别在镜像里装 go、bee 或跑 bee run —— 那是开发态，不是部署态。
Beego 项目必须提前切到 prod 模式
Beego 默认是 dev 模式，会热重载、开调试面板、暴露敏感路径（如 /beego/swagger），容器里一跑就报错或被扫出漏洞。
- 修改
conf/app.conf，确保有runmode = prod - 检查
httpport是否设为你期望的端口（比如8090），别依赖默认8080 - 确认
EnableGzip = true和CopyRequestBody = true等关键项已按需开启 - 如果用了模板（
views/）或静态资源（static/），要确保路径在运行时可访问 ——beego.SetViewsPath()和beego.SetStaticPath()必须显式调用，不能靠默认值
Dockerfile 要分阶段构建，最终只留二进制 + 配置 + 静态文件
镜像体积大、攻击面宽、启动慢，基本都源于没做多阶段构建。Go 编译不依赖运行时，没必要把 golang:alpine 当最终镜像。
- 第一阶段用
golang:1.21-alpine（别用latest）编译：COPY . /app→cd /app && go build -o /app/beego-app -ldflags="-s -w" - 第二阶段用
alpine:3.20，只COPY --from=0 /app/beego-app /usr/local/bin/beego-app - 再
COPY conf/app.conf /etc/beego/app.conf，COPY static/ /var/www/static/，COPY views/ /var/www/views/ -
EXPOSE 8090，ENTRYPOINT ["/usr/local/bin/beego-app"]—— 不要用sh -c包一层
运行容器时必须挂载配置或覆盖环境变量
硬编码在 app.conf 里的数据库地址、密码、密钥，绝对不能打进镜像。否则每次改配置都要重打镜像，CI/CD 彻底失效。
- 用
-v $(pwd)/prod.conf:/etc/beego/app.conf:ro替换整个配置文件 - 或用 Beego 支持的环境变量覆盖机制：
docker run -e BEEGO_HTTPPORT=8090 -e BEEGO_DB_HOST=db.example.com ... - 注意 Beego 环境变量名是全大写、下划线分隔，且前缀为
BEEGO_（例如BEEGO_RUNMODE对应runmode） - 如果用了 MySQL，记得在
docker run里加--network连到 DB 容器网络，别信localhost—— 容器里localhost是自己
别忽略 Beego 的文件路径绑定时机
Beego 在 beego.Run() 前才加载配置和设置路径，但如果你在 init() 或包级变量里就访问了 beego.BConfig 或试图读 views/，会 panic：找不到目录。
- 所有路径设置（
SetViewsPath、SetStaticPath）务必放在main()开头、beego.Run()之前 - 不要依赖
beego.AppPath自动推导 —— 容器里工作目录不可靠，显式用os.Executable()或os.Args[0]反推根路径更稳 - 测试方法：进容器执行
ls -l /var/www/views和cat /etc/beego/app.conf | grep httpport，确认内容和权限都对
