gomaxprocs必须对齐容器cpu配额而非宿主机核数，应优先读环境变量或从cgroup动态计算（v2读/cpu.max、v1读cpu.cfs_quota_us/cpu.cfs_period_us并向上取整），kubernetes中推荐用downward api注入limits.cpu；gogc非万能，gomemlimit才是防oom第一道防线，需设为略高于压测常驻内存（如850mb→1gb），单位不区分大小写且不可带引号；cgo_enabled=0为高并发dns解析刚需，http连接池参数（maxidleconns、idleconntimeout等）必须显式配置，否则性能严重受限。
GOMAXPROCS 必须对齐容器 CPU 配额，不能信 runtime.NumCPU()
Go 进程在容器里默认读取宿主机逻辑核数，比如宿主机 64 核、容器只分到 --cpus=1.8，runtime.NumCPU() 仍返回 64，GOMAXPROCS 被设成 64 后，所有 goroutine 实际挤在不到 2 个可用 CPU 上争抢调度，表现为 CPU 利用率忽高忽低、P99 延迟毛刺明显。
- 正确做法：启动时优先读环境变量
GOMAXPROCS；若未设，从 cgroups 接口动态算——cgroup v2 读/sys/fs/cgroup/cpu.max（格式如180000 100000），向上取整得 2；v1 读/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us，相除后向上取整 - Kubernetes 中推荐用 Downward API 注入：
valueFrom: {resourceFieldRef: {resource: limits.cpu}}，避免硬编码 - 常见错误：
ENV GOMAXPROCS=0（等于没设）、value: "2"（带引号会被 Go runtime 忽略）、runtime.GOMAXPROCS(2)与环境变量共存（后者优先但代码调用会覆盖，易混乱）
GOGC 不是越小越好，GOMEMLIMIT 才是防 OOM 的第一道防线
GOGC=20 是高频分配场景的常见值，但它只控制堆增长比例触发 GC；而容器被 OOMKilled 往往不是因为堆爆了，而是整个进程虚拟内存（含栈、mcache、bypass cache 等）逼近 limit。Go 1.19+ 的 GOMEMLIMIT 才真正作用于这个层面。
-
GOMEMLIMIT单位支持B/KB/MB/GB（不区分大小写），设为略高于压测实测常驻内存，例如稳定占用 850MB → 设GOMEMLIMIT=1GB - 和
GOGC共存时，GOMEMLIMIT优先级更高：哪怕堆才涨了 10%，只要总内存快到上限，GC 就强制触发 - 错误写法：
export GOGC="50"（引号导致解析失败）、GOMEMLIMIT=256MB（太低引发 GC 频繁、CPU 反升）、GOMEMLIMIT=4GB（失去保护意义） - 运行时可调：
debug.SetMemoryLimit(900 * 1024 * 1024)，比环境变量更灵活，适合灰度验证
CGO_ENABLED=0 是大并发长连接的刚需，不是可选项
默认启用 CGO 时，net 包底层调用 libc 的 getaddrinfo 做 DNS 解析，该调用阻塞且不可中断，高并发下极易卡住 goroutine——典型现象是 pprof 显示大量 goroutine 停在 runtime.gopark + syscall.Syscall6。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 编译必须加：
CGO_ENABLED=0 go build -ldflags="-s -w" -o server ./main.go - 禁用后 DNS 走纯 Go 实现（
net/dnsclient.go），支持context.WithTimeout中断，不依赖系统/etc/resolv.conf顺序 - 副作用：无法使用 OpenSSL、SQLite 等 C 绑定库；若必须用，需单独为 DNS 模块打补丁，或改用
github.com/miekg/dns - 别在启动脚本里 export CGO_ENABLED=0——它只影响构建阶段，运行时无效
HTTP Server 和 Client 的连接池参数不设等于自缚手脚
未配置的 http.Server 或沿用 http.DefaultClient，在高并发下会迅速暴露瓶颈：QPS 卡在 200–300、netstat 显示大量 TIME_WAIT 或 ESTABLISHED 堆积、延迟突增。
-
MaxIdleConns和MaxIdleConnsPerHost必须显式设为相同值（如 1000），否则跨域名请求抢不到空闲连接 -
IdleConnTimeout设为略大于后端平均响应时间（如5 * time.Second），太短反复建连，太长耗尽 fd -
ReadTimeout/WriteTimeout必须设（建议 ≤5 * time.Second），防止慢请求长期占着 goroutine - 禁止复用
http.DefaultClient——压测中它共享的 Transport 会因连接池过小直接阻塞；应new(&http.Client{...})独立实例
实际调参不是一步到位的事。最常被忽略的是：GOMEMLIMIT 的单位写错（比如写成 1g 而非 1GB）、GOMAXPROCS 在 Kubernetes 里没用 Downward API 动态注入、以及 HTTP 连接池参数漏配任意一项就足以让性能掉档。这些点不靠压测数据看不出问题，一出线上故障才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
