关键在于构建阶段是否剥离构建依赖、运行阶段是否最小化攻击面、环境变量和端口是否对齐Fiber默认行为；三点未处理好导致90%部署失败。
直接用 Dockerfile 构建镜像、docker run 启动容器就能跑起来，但关键在于构建阶段是否真正剥离了构建依赖、运行阶段是否最小化攻击面、环境变量和端口是否与 Fiber 默认行为对齐——这三点没处理好，90% 的部署失败都发生在这里。
为什么不能直接用 golang:alpine 作为最终运行镜像
Fiber 应用在构建后是静态二进制，理论上可以扔进 scratch 镜像。但实际中常见问题包括：
-
CGO_ENABLED=0必须显式关闭，否则会链接 libc，导致scratch镜像启动时报no such file or directory - 若代码里用了
net/http/pprof或日志写文件，可能隐式依赖/dev/pts或/proc，scratch不提供这些路径 -
alpine虽小，但自带musl，比scratch多几 MB，却能兼容绝大多数 syscall 和路径操作，更稳妥
建议最终运行阶段使用 alpine:3.19（当前最新稳定版），而非 scratch，除非你已确认应用完全无外部路径依赖。
如何正确暴露 Fiber 的监听地址和端口
Fiber 默认监听 127.0.0.1:3000，这在容器内会导致外部无法访问。必须显式绑定到 0.0.0.0：
app.Listen("0.0.0.0:3000")
同时注意 Docker 层的端口映射要匹配：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 应用代码中端口写死为
3000→docker run -p 8080:3000是安全的 - 若想从环境变量读取端口（推荐），代码中应改为：
app.Listen("0.0.0.0:" + os.Getenv("PORT")) - 对应的
docker run命令需加-e PORT=8080，且Dockerfile中不要硬编码EXPOSE 3000，而应写EXPOSE ${PORT}（需用build-arg支持）
构建阶段常见的 go mod 缓存失效问题
很多 Dockerfile 直接 COPY . . 再 go build，结果每次构建都重新下载全部依赖，慢且不可复现。正确做法是分层缓存：
- 先
COPY go.mod go.sum .→ 触发go mod download，这步缓存命中率极高 - 再
COPY . .→ 只有源码变更时才失效，不影响依赖层 - 避免在
go build前执行go mod tidy，它会修改go.sum，导致缓存失效 - 如项目含 cgo 依赖（比如 sqlite、pq），构建阶段必须保留
CGO_ENABLED=1，且基础镜像得带gcc，不能用golang:alpine简单替代
健康检查端点怎么配才不误判
Fiber 没内置 /health，得自己加路由。但别简单返回 200 OK，要体现真实就绪状态：
app.Get("/health", func(c *fiber.Ctx) error {
// 检查数据库连接
if err := db.Ping(); err != nil {
return c.Status(fiber.StatusServiceUnavailable).SendString("db down")
}
// 检查 Redis（如果用了）
if err := redisClient.Ping(c.Context()).Err(); err != nil {
return c.Status(fiber.StatusServiceUnavailable).SendString("redis down")
}
return c.SendStatus(fiber.StatusOK)
})
然后在 docker run 里加健康检查：
docker run \ --health-cmd="curl -f http://localhost:3000/health || exit 1" \ --health-interval=30s \ --health-timeout=3s \ --health-retries=3 \ -p 3000:3000 fiber-app
注意：Docker 默认用 localhost 检查，不是容器 IP；若用 docker-compose，健康检查命令得改用 http://127.0.0.1:3000/health，否则可能因网络命名空间问题失败。
最易被忽略的是：Fiber 的 app.Config().CaseSensitive 和 StrictRouting 默认为 false，但在容器化后若前端反向代理（如 Nginx）做了路径重写，大小写或尾部斜杠不一致就会 404——这个问题不会在本地开发暴露，只会在容器里静默失败。
