Beego项目开发阶段可用bee run实现热重载，但生产环境严禁使用；必须通过go build编译为单体二进制后运行，配合alpine多阶段Docker构建、关闭cgo、设置runmode=prod及显式指定views/static路径。
Beego项目必须用 bee run 吗？别这么干
生产环境绝对不要用 bee run 启动 Beego 服务。它只适合开发阶段热重载，会启动 watchdog、扫描源码、依赖未编译的 .go 文件，容器里没装 go 编译器就直接报错——常见错误是 exec: "go": executable file not found in $PATH 或 cannot find package。
正确做法是：先在宿主机或构建阶段完成编译，生成单体二进制，再 COPY 进精简镜像运行。Beego 项目默认输出名就是项目目录名（如 myapp），无需额外指定 -o。
- 确保
main.go在项目根目录，且已调用beego.Run() - 构建时加
-ldflags="-s -w"减小体积（可选但推荐） -
ENTRYPOINT ["./myapp"]必须和实际二进制名严格一致，大小写敏感 - 避免在
Dockerfile中执行go get github.com/astaxie/beego—— 它会拉取最新版，破坏版本锁定
Dockerfile 应该基于 golang 还是 alpine？选后者但要小心
用 golang:1.21-alpine 多阶段构建最稳妥：第一阶段用完整 golang 镜像编译，第二阶段用 alpine:latest 运行，最终镜像通常压到 15–25MB。如果硬要用单阶段 golang 镜像，体积会超 1GB，且含大量开发工具，存在安全风险。
注意 Alpine 的 libc 是 musl，而 Beego 默认依赖 cgo（尤其连 MySQL 时）。若遇到 undefined reference to 'clock_gettime' 或数据库连接失败，需显式关闭 cgo：
- 构建前加
ENV CGO_ENABLED=0 - 使用纯 Go 驱动：MySQL 改用
github.com/go-sql-driver/mysql（默认支持），PostgreSQL 改用github.com/lib/pq - 确认
conf/app.conf中runmode = prod已设置，否则模板路径、静态资源可能加载失败
端口暴露和容器启动参数怎么配才不出错
Beego 默认监听 0.0.0.0:8080，但配置文件 conf/app.conf 中的 httpport 才是真实生效值。Docker 层面只需做两件事：EXPOSE 声明（仅文档作用）、-p 映射（实际生效）。别信 “EXPOSE 能让端口对外可访问” —— 它只是元数据。
-
EXPOSE 8090不等于开放防火墙端口，宿主机仍需手动放行（如ufw allow 8090） -
docker run -p 8090:8090中右边端口必须和app.conf里httpport一致，否则 Beego 绑定失败，日志报listen tcp :8080: bind: address already in use（其实是绑定到了 8090，但你映射错了） - 别加
--network host：它绕过 Docker 网络栈，导致 Beego 获取不到真实请求 IP（c.Ctx.Input.IP()返回 127.0.0.1） - 挂载配置文件用
-v $(pwd)/conf/app.conf:/go/src/myapp/conf/app.conf:ro，加:ro防止容器内误改
为什么容器启动后立刻退出？检查这三处
典型现象：docker run 后马上 Exited (1)，docker logs 空或只有几行 panic。这不是 Beego 的锅，是容器生命周期管理没对齐。
- 确认
ENTRYPOINT或CMD是前台进程：Beego 二进制本身是阻塞的，但若前面加了sh -c或包装脚本没加exec，主进程退出后容器立即终止 - 检查
conf/app.conf是否缺失关键段落，比如漏掉[database]但代码里又调用了orm.RunSyncdb，会 panic 退出 - Beego 的
views和static路径默认从当前工作目录推导，容器里若没把views/目录 COPY 进去，首次访问页面就 panic：无法加载模板。必须显式设置：beego.SetViewsPath("/go/src/myapp/views")（路径以容器内为准）
最易被忽略的是：Beego 在 prod 模式下不自动重载配置，改了 app.conf 必须重启容器；而很多人以为改完配置就能热生效，结果行为和本地开发不一致，排查半天才发现是缓存或路径问题。
