GOMAXPROCS必须设为容器CPU限制向上取整的整数（如--cpus=1.2→2），GOGC和GOMEMLIMIT需结合压测结果协同调优，不可套用默认值；三者相互影响，必须通过真实负载验证效果。
GOMAXPROCS 必须设为容器 CPU 限制向上取整的整数，GOGC 和 GOMEMLIMIT 要配合压测结果设置，不能直接套用默认值或别人的经验值。
容器里 GOMAXPROCS 设多少才不浪费也不争抢
Go 进程在容器中默认读取宿主机逻辑核数，但资源紧张时，容器往往只被分配了非整数 CPU（如 --cpus=1.2），此时若不做干预，调度器会频繁抢占或闲置 goroutine。
-
GOMAXPROCS应设为ceil(容器 CPU 限制)：比如--cpus=1.2→GOMAXPROCS=2；--cpus=0.8→GOMAXPROCS=1 - 错误写法：
ENV GOMAXPROCS=0（等于没设）；Kubernetes 中写value: "2"（带引号会被 runtime 忽略） - 推荐方式：在启动命令中显式赋值，例如
sh -c 'GOMAXPROCS=2 exec ./myapp'，避免环境变量与代码中runtime.GOMAXPROCS()冲突
GOGC=20 并不适合所有内存受限场景
GOGC 控制的是堆增长比例触发 GC 的阈值，不是“越小越好”。设为 20 意味着堆中存活对象每涨 20% 就触发一次 GC，GC 频次高、CPU 占用上升，但单次停顿短。它只在明确观测到 OOMKilled 或堆持续逼近 limit 时才值得启用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
GODEBUG=gctrace=1观察 GC 频率和 STW 时间，再决定是否调低 - 若容器
memory limit=512MiB，实测稳定堆占用约 380MiB，可尝试GOGC=50，而非盲目设 20 - 必须写成无引号的裸数字：
GOGC=50✅，GOGC="50"❌（runtime 解析失败） - 运行时可动态调整：
old := runtime.SetGCPercent(50)，返回旧值便于快速回滚
GOMEMLIMIT 是比 GOGC 更可靠的内存保险丝
自 Go 1.19 起，GOMEMLIMIT 成为防 OOM 的关键防线——它限制整个进程虚拟内存上限（含堆、栈、代码段等），一旦接近该值，GC 会强制提前触发，比依赖堆增长比例更底层、更确定。
- 压测得出常驻内存 750MB → 设
GOMEMLIMIT=900MB（留 150MB 缓冲） - Kubernetes 中建议直接写进 env：
{"name": "GOMEMLIMIT", "value": "1GB"}，单位不区分大小写 - 与
GOGC共存时，GOMEMLIMIT优先级更高：哪怕堆只涨了 10%，只要总内存快到 1GB，GC 照样启动 - 设得太低（如
GOMEMLIMIT=256MB）会导致 GC 频繁、CPU 反升；设得太高（如4GB）等于没设
真正难的不是记住参数含义，而是把 GOMEMLIMIT、GOGC、GOMAXPROCS 放在一起跑压测，看它们如何相互影响——比如调低 GOGC 后 GOMEMLIMIT 是否还够用，或者 GOMAXPROCS 变小后 GC 停顿是否反而变长。这些组合效应，必须靠真实负载验证，没法靠推理猜出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
