Revel CLI 必须在构建阶段（builder 镜像）用 go install 安装，不可在运行时容器中安装；因 Alpine 运行镜像无 Go 环境，强行安装会膨胀镜像、违背多阶段构建原则，且生产镜像只需静态二进制和基础依赖。
Revel 框架本身不“安装”在容器里，而是通过 go install 在构建阶段把 revel CLI 工具编译进 builder 镜像，再用它构建应用可执行文件——这是唯一可靠、符合 Revel 生产部署逻辑的做法。
为什么不能在运行时容器里装 revel CLI
Alpine 运行镜像（如 alpine:3.18）不含 Go 编译环境，go install 无法执行；若强行在运行镜像中装 Go 再装 revel，会大幅膨胀镜像、引入冗余依赖，且违背多阶段构建原则。生产镜像只需要最终二进制和运行时依赖（如 ca-certificates）。
必须在 builder 阶段用 go install 安装 revel
你得在 Dockerfile 的 FROM golang:1.21-alpine AS builder 阶段显式安装 CLI：
-
RUN go install github.com/revel/cmd/revel@latest是当前最稳妥的写法（避免版本漂移） - 不要用
go get—— Go 1.21+ 已弃用，且go get默认不安装到$GOBIN，可能导致revel命令找不到 - 确认安装成功：可在
RUN后加RUN revel version调试（仅构建期，不影响最终镜像） - 如果项目依赖旧版 Revel（如 v0.19.0），需指定 commit 或 tag：
go install github.com/revel/cmd/revel@v0.19.0
revel build 生成的二进制才是容器真正要运行的东西
容器最终运行的不是 revel run，而是 revel build 输出的可执行文件：
-
RUN revel build -a . -t /app/target必须在 builder 阶段完成，它会把整个应用打包成单个二进制 - 目标路径（如
/app/target）要和后续COPY --from=builder的源路径严格一致 - 生成的二进制默认不带调试符号，但若需 trace 或 pprof，构建时加
-ldflags="-s -w"会丢失符号表——Revel 未暴露该参数入口，所以别硬改；如真需要，应改用go build替代revel build -
CMD ["./target"]中的target名称必须与revel build -t指定的一致，大小写敏感
容易被忽略的是：revel build 会读取项目根目录下的 conf/app.conf，并把其中 app.name、run.mode 等配置静态嵌入二进制。这意味着你不能靠环境变量覆盖 run.mode 来切开发/生产模式——必须在构建前就确定好配置，或用 docker-compose.yml 的 environment 配合 conf 中的 ${RUN_MODE} 占位符（前提是 Revel 版本 ≥ 0.25 且启用了 env 解析）。
