Beego项目Docker生产部署核心是避坑：必须编译二进制、设runmode=prod、显式配置绝对路径（如beego.SetViewsPath）、分阶段构建镜像、监听0.0.0.0、防火墙与安全组同步开放端口。
Beego 项目用 Docker 部署，核心不是“能不能”，而是“怎么避免踩坑”——尤其是生产环境里 bee run 绝对不能上，app.conf 的 runmode 必须设为 prod，且静态资源路径、配置加载逻辑在容器里极易失效。
Beego 项目必须先编译成二进制，别用 bee run
开发时用 bee run 是为了热重载，但容器里没意义，还带一堆 dev 依赖（比如 fsnotify），镜像臃肿、启动慢、有安全隐患。生产镜像应该只含可执行文件 + 配置 + 静态资源。
- 本地编译命令要指定目标平台：Linux 容器必须用
GOOS=linux GOARCH=amd64 go build -o mindoc（别用 Windows 或 macOS 默认编译） - 确保
main.go中已显式设置路径，否则容器内找不到views或static：beego.SetViewsPath("/app/views")、beego.SetStaticPath("/app/static") -
app.conf里必须有runmode = prod，否则 Beego 会尝试加载 dev 模式下的调试中间件，导致启动失败或端口监听异常
Dockerfile 要分阶段构建，别直接用 golang:latest 运行
把编译和运行拆开，能大幅减小最终镜像体积（从 1GB+ 降到 ~20MB），也避免把 go、git 等工具留在生产镜像里。
- 第一阶段用
golang:1.21-alpine编译（Alpine 更小，注意 Beego 对musl兼容性良好） - 第二阶段用
alpine:latest或scratch，仅 COPY 编译好的二进制、conf/、views/、static/ - 务必用
COPY --chown=root:root显式设定权限，否则 Alpine 下非 root 用户可能无法读取配置文件 -
EXPOSE只是声明，真正生效靠beego.BConfig.Listen.HTTPPort = 8080或app.conf里的httpport配置
docker-compose.yml 中的环境变量和挂载要匹配 Beego 配置加载逻辑
Beego 默认按顺序加载：os env → app.conf → default.conf。如果用环境变量覆盖数据库地址，就得在 app.conf 里写成 db_host = ${MINDOC_DB_HOST}，并启用 beego.AppConfig.SetEnv(true)（Go 代码中）或确保 app.conf 格式支持变量替换（ini 格式原生不支持，需手动解析）。
- 推荐做法：把
app.conf放进镜像，再用volumes挂载外部配置覆盖关键项（如数据库密码），避免敏感信息硬编码 - 挂载
uploads/目录时，宿主机路径需提前chown -R 1001:1001 /path/to/uploads（Alpine 默认非 root 用户 UID 为 1001），否则 Beego 写入失败报permission denied -
depends_on只控制启动顺序，不保证依赖服务就绪；Beego 启动时若连不上 MySQL，会 panic 退出，建议加健康检查或启动脚本重试
端口和防火墙配置容易漏掉真实监听地址
Beego 默认监听 127.0.0.1:8080，但在容器里必须改成 0.0.0.0:8080，否则宿主机映射无效。这个细节常被忽略，现象是 curl localhost:8080 返回空或连接拒绝，但容器日志显示 “server started”。
- 改法一：在
app.conf加httpaddr = 0.0.0.0 - 改法二：代码中调用
beego.BConfig.Listen.HTTPAddr = "0.0.0.0" - 宿主机防火墙（如 CentOS 的 firewalld）必须开放映射后的宿主端口（比如
-p 8080:8080就要开 8080，不是容器内 8080） - 云服务器（如阿里云、腾讯云）安全组也要放行对应端口，这个比本地防火墙更容易被遗忘
最易被跳过的其实是 Beego 的路径初始化逻辑：容器里工作目录、二进制位置、相对路径全变了，beego.AppPath 不再指向项目根，所有基于 ./conf 的加载都会失败——必须用绝对路径或 os.Executable() 反推根路径，否则上线后首页 404、配置读不到、静态资源 404，问题分散，排查成本高。
