Go容器应单进程运行，直接ENTRYPOINT二进制并正确处理信号；静态编译、调优GOMAXPROCS/GOGC；用distroless镜像；设HTTP超时、避免DNS阻塞、用pprof定位真实瓶颈。

避免在容器内启动多个进程

Go 程序天生适合单进程部署，但有人会习惯性用 supervisord 或 shell 脚本拉起多个服务（比如 Go 服务 + 日志轮转 + 健康检查脚本），这不仅浪费内存，还会干扰容器生命周期管理。Docker 的 ENTRYPOINT 应直接指向你的 Go 二进制，由它自己处理信号（如 SIGTERM）和优雅退出。

• 确保 main() 中监听 os.Interrupt 和 syscall.SIGTERM，并关闭 HTTP server、DB 连接池等资源
• 不要在 Dockerfile 中用 CMD ["/bin/sh", "-c", "go run ..."] —— 这会多一层 shell，且无法正确转发信号
• 构建时用 CGO_ENABLED=0 go build -a -ldflags '-s -w'，生成静态链接、无调试信息的二进制，减小体积并避免运行时依赖

合理设置 GOMAXPROCS 和 GC 参数

容器环境常被限制 CPU 核心数（如 --cpus=1.5 或 cpu.shares），而 Go 默认将 GOMAXPROCS 设为系统逻辑核数，会导致 goroutine 调度争抢或闲置。GC 频率也受容器内存限制影响——若只给 256MiB 内存却未调低 GOGC，可能每秒触发多次 GC，拖慢吞吐。

• 启动前显式设置：GOMAXPROCS=2（建议设为 ceil(LimitCPU / 1000)，单位是 millicores）
• 内存受限时降低 GC 频率：GOGC=20（默认 100，值越小越激进；20 表示堆增长 20% 就触发 GC）
• 避免在代码中调用 runtime.GC()，它会阻塞所有 goroutine，且无法解决根本压力问题

使用 distroless 基础镜像并精简 layer

基于 golang:1.22-alpine 构建再拷出二进制，不如直接用 gcr.io/distroless/static:nonroot。前者包含 apk、shell、ca-certificates 等冗余组件，增大攻击面与镜像体积；后者仅含运行时必需文件，且默认以非 root 用户运行。

• Dockerfile 中用 multi-stage：第一阶段用 golang:1.22 编译，第二阶段 FROM gcr.io/distroless/static:nonroot 并 COPY --from=0 /app/myserver /myserver
• 删除所有不必要的 ADD/COPY，避免缓存失效导致整层重建；敏感配置（如密钥）绝不在镜像中写死
• 验证最终镜像：运行 docker run --rm -it ls -l /，确认只有 /myserver、/dev、/etc/ssl/certs 等极少数路径存在

监控真实瓶颈：别只看 CPU 和内存

Go 服务卡顿，常被误判为 CPU 不够，实际可能是网络延迟、DNS 解析阻塞、或 net/http 默认 client 没配超时。容器网络栈叠加（host → docker0 → veth → 容器 netns）也会引入微秒级延迟，在高 QPS 场景下不可忽略。

立即学习“go语言免费学习笔记（深入）”；

• 用 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 抓 CPU profile，重点看 runtime.selectgo 或 net.(*pollDesc).wait 占比是否异常高
• HTTP client 必须设超时：

  http.DefaultClient = &http.Client{Timeout: 5 * time.Second}

  ，否则一次失败请求可能 hang 住整个 goroutine
• DNS 解析尽量用 IP 或启用 net.Resolver 缓存；避免在 handler 中调用 net.LookupIP

Go 容器性能问题往往藏在“默认行为”里——比如没关 GC、没设 GOMAXPROCS、用了带 shell 的启动方式、或者把调试用的 base 镜像直接推到生产。这些点不难改，但一旦漏掉一个，就可能让 QPS 掉一半，还查不出原因。