pprof定位到json.Unmarshal占比超30%，本质是序列化热路径，应避免盲目换库，优先复用解析结果、上游预处理、延迟解析非关键字段或改用事件驱动替代高频轮询。
热路径（hot path）CPU占用高，本质是同一段代码被高频执行且未做有效收敛。直接加 sleep 或降频调用只是掩盖问题，真正要做的，是让这段逻辑“变轻”或“变少”。
pprof 定位到 json.Unmarshal 占比超 30% 怎么办
这是典型的数据序列化热路径。常见于任务分发、配置加载、API 响应解析等场景。
- 别急着换 jsoniter——它能提速，但无法解决根本的“重复解析同一份数据”问题
- 检查是否在循环里反复
json.Unmarshal同一批原始字节：把[]byte缓存为结构体指针，复用而非重解析 - 如果数据来自外部（如 Redis、DB），考虑在上游做预处理：把 JSON 字段提前反序列化并缓存为 Go struct，业务层直取
- 字段过多时，用
json.RawMessage延迟解析非关键字段，避免整块解包开销
for {} 空转或高频轮询导致 CPU 拉满
比如监听状态、等待信号、健康检查轮询，没有休眠就等于让 OS 调度器不停切 goroutine。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 绝对不要写
for { doSomething(); }—— 至少加time.Sleep(10 * time.Millisecond) - 用
time.Ticker替代手动 sleep，避免 drift 和累积误差 - 更优解是事件驱动：用
chan struct{}+select等待真实信号，而不是猜“现在有没有变化” - 若必须轮询，把间隔设为可配置，并在低峰期自动延长（例如从 100ms → 2s）
GOMAXPROCS 与容器 CPU 限额不匹配引发调度抖动
在 Kubernetes 或 Docker 中，runtime.NumCPU() 返回的是宿主机核数，不是容器实际能用的核数。
立即学习“go语言免费学习笔记（深入）”；
- 现象：top 显示单核 100%，但
htop看到大量 goroutine 在 RUNNABLE 状态排队 - 启动前强制设置：
runtime.GOMAXPROCS(int(os.Getenv("GOMAXPROCS")))，配合 Downward API 注入 - 更健壮的做法：读
/sys/fs/cgroup/cpu.max（cgroup v2）算出可用核数，向下取整后调用runtime.GOMAXPROCS - 注意：GOMAXPROCS 不是越大越好；设为容器 CPU limit 的整数倍（如 limit=2 → GOMAXPROCS=2）通常最稳
热路径优化最难的不是改代码，而是判断“这里到底值不值得优化”。有时候花两天把一个 5% 的 flat% 函数内联掉，不如砍掉一次不必要的远程调用。优先盯 cum% 高、调用频次明确、且不在第三方库里的函数——它们才是你真正能动手的地方。
