不能直接用 golang 镜像运行 Fiber 服务，因为需多阶段构建：构建阶段用 golang 镜像编译静态二进制，运行阶段用 alpine 或 scratch 运行，否则镜像含完整 Go 工具链，体积大（~400MB）、启动慢（go run 冷启动）、有安全风险。
直接用 FROM golang:1.22-alpine 构建镜像会失败——因为 Fiber 应用最终要运行的是二进制文件，不是源码，必须做多阶段构建，否则镜像里塞了整个 Go 工具链，体积大、启动慢、有安全风险。
为什么不能直接用 golang 镜像运行 Fiber 服务
常见错误是写成这样：
FROM golang:1.22-alpine WORKDIR /app COPY . . CMD ["go", "run", "main.go"]
这会导致容器启动时每次都要编译，既不符合生产环境“一次构建、多次运行”的原则，又暴露了源码和构建工具。Fiber 基于 fasthttp，对启动延迟极其敏感，go run 的冷启动开销完全不可接受。
- 镜像体积从 ~15MB 暴涨到 ~400MB（含 Go SDK + build deps）
- 容器健康检查（
HEALTHCHECK）容易因编译超时失败 - Docker 层缓存失效频繁，CI/CD 构建时间不可控
标准多阶段构建 Dockerfile 写法
核心思路：构建阶段用 golang 镜像编译出静态二进制，运行阶段用 alpine:latest 或 scratch 运行。
- 务必加
-ldflags="-s -w"去除调试符号和 DWARF 信息，减小二进制体积 - 使用
CGO_ENABLED=0确保生成纯静态链接，避免 alpine 上缺失 libc 动态库 -
WORKDIR /app和COPY --from=builder路径必须严格匹配，否则./server找不到
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o server . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/server . EXPOSE 3000 HEALTHCHECK --interval=10s --timeout=3s --start-period=15s --retries=3 \ CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1 CMD ["./server"]
Fiber 启动参数与容器健康检查对齐
Fiber 默认不暴露 /health 路由，HEALTHCHECK 会一直失败。你得自己加一个轻量端点，且不能依赖中间件（比如 JWT 验证、日志记录），否则健康探针可能被卡住或误判。
- 不要用
c.Status(200).SendString("OK")——SendString不设 Content-Type，某些探针（如 Kubernetes livenessProbe）可能拒绝响应 - 推荐用
c.SendStatus(fiber.StatusOK)，零内存分配，符合 Fiber 风格 - 避免在
/health里查数据库或 Redis，它只应反映进程存活状态
示例代码片段：
app.Get("/health", func(c fiber.Ctx) error {
return c.SendStatus(fiber.StatusOK)
})
部署到 Kubernetes 时的资源限制陷阱
Fiber 的 goroutine 池和连接复用高度依赖系统资源，但很多人在 resources.limits 里只设 memory: 128Mi，结果容器频繁 OOMKilled——不是因为内存真爆了，而是 Linux OOM Killer 看到进程 RSS 超过 limit 就杀。
- Fiber 默认启用
fasthttp的连接池，每个活跃连接约占用 64KB 内存，100 并发就接近 6.4MB，加上日志缓冲、对象池，128Mi 实际撑不住 - 建议起始值设为
memory: 256Mi，CPU limit 可设100m（即 0.1 核），避免被调度器限频影响吞吐 - 若用
fiberhouse框架，它内置的全局管理器会预分配 goroutine 池，更需预留内存余量
真正容易被忽略的点：Docker 构建时没关掉 GOBINARY 环境变量，或者本地 go env -w GOOS=linux 没生效，导致交叉编译失败却报错模糊——这时候看 docker build 日志末尾的 exec: "gcc": executable file not found in $PATH 就知道是 CGO 没关干净。
