Fiber容器curl不通的最常见原因是应用监听127.0.0.1而非0.0.0.0；必须确保app.Listen(":3000")（等价于0.0.0.0:3000），并用netstat验证输出含*:3000，同时Dockerfile分阶段构建、端口正确映射、容器内绑定地址无误。
直接说结论：用 Docker 部署 Fiber 应用，核心就三步——写对 Dockerfile、暴露正确端口、容器内监听 0.0.0.0 而非 127.0.0.1。漏掉任一环节，服务就访问不到。
为什么 Fiber 容器启动后 curl 不通？
最常见原因是应用在容器里仍监听 127.0.0.1:3000，而 Docker 容器网络模型要求服务必须绑定到 0.0.0.0 才能被宿主机或外部访问。
检查你的 main.go 启动代码：
app.Listen(":3000") // ✅ 正确：等价于 0.0.0.0:3000
// app.Listen("127.0.0.1:3000") // ❌ 错误：仅本机回环可访问
- Fiber 默认
Listen()就是0.0.0.0，但如果你显式写了"127.0.0.1"或通过环境变量拼接地址，就会失败 - 用
netstat -tuln进入容器验证：docker exec -it fiber-container sh -c "netstat -tuln | grep :3000"，输出中应含*:3000，而非127.0.0.1:3000 - 开发时本地能跑 ≠ 容器能跑，别跳过这一步验证
Dockerfile 必须做对的几件事
Go 编译型语言，Dockerfile 分两阶段构建最稳妥。关键不是“能不能跑”，而是“能不能小、能不能快、能不能安全”。
- 构建阶段用
golang:1.20-alpine（或匹配你go.mod的版本），避免用latest导致构建不可重现 - 务必加
CGO_ENABLED=0 GOOS=linux，否则编译出的二进制可能依赖 glibc，在 alpine 上直接报错no such file or directory - 运行阶段用
alpine:3.17或更新版（如3.20），别用scratch—— Fiber 日志、pprof 等调试能力会失效，排障成本陡增 -
COPY --from=builder只复制最终二进制，不带/app源码和go.mod，减小镜像体积且提升安全性
docker run 命令里最容易错的参数
不是 -d 或 --name，而是端口映射和健康检查缺失。
-
-p 3000:3000是基础，但生产建议加--restart=unless-stopped，防止 Docker 重启后服务没起来 - 别省略
--health-cmd：Fiber 默认有/health或你可以加个简单路由，例如app.Get("/health", func(c *fiber.Ctx) error { return c.SendStatus(fiber.StatusOK) })，然后运行时加参数：--health-cmd="curl -f http://localhost:3000/health || exit 1" --health-interval=30s - 如果用
docker-compose.yml，记得设restart和healthcheck字段，否则 K8s 外部编排时容器异常退出不会自动拉起
部署到 Kubernetes 前必须确认的点
K8s 不是 Docker 的放大版，它对资源、探针、权限更敏感。
-
deployment.yaml中containerPort必须和 Fiber 实际监听端口一致（默认3000），且ports[].name建议设为http，方便 Istio 等服务网格识别 - Liveness/Readiness 探针不能只靠
httpGet，Fiber 启动慢时（比如连 DB、加载配置），要设initialDelaySeconds: 10，否则 K8s 会反复 kill restart - 资源
requests必须填，哪怕很小（如cpu: 100m），否则在 namespace 有 ResourceQuota 时 Pod 直接 Pending - 别在容器里用
root用户跑 Fiber，默认 Alpine 镜像用户是root，但 K8s 安全策略常禁止，得加runAsNonRoot: true和runAsUser: 1001，并在 Dockerfile 里useradd -u 1001 appuser && chown -R appuser /app
真正卡住人的从来不是“怎么写 Dockerfile”，而是容器启动后日志里没有报错、docker ps 显示 Up、但 curl 就是超时——这时候先 exec 进去盯 netstat，再查 app.Listen() 参数，最后翻一遍 docker run 的完整命令。顺序错了，排查时间翻倍。
