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 掉一半，还查不出原因。
