big.int频繁new导致runtime.mallocgc飙升是gc压力暴涨主因；应复用实例、sync.pool配合z.set(nil)重置、预分配abs底层数组，并避免exp/mod等方法误用接收器。
big.Int频繁new导致runtime.mallocgc飙升
直接在循环里写 new(big.Int) 或 big.NewInt(0)，是加密、哈希、RSA签名等场景下 GC 压力暴涨的头号原因。pprof 看到 runtime.mallocgc 占 CPU 40%+，基本就是它。
- 每次
new(big.Int)都分配堆内存，big.Int内部abs字段是[]big.Word，扩容+GC 双重开销 - 实测：1024 位模幂运算中复用 vs 每次 new，耗时差 3–5 倍（80μs → 300μs）
- 错误写法：
res := new(big.Int).Exp(base, exp, mod)—— 每次都新对象，还立刻丢弃 - 正确写法：
res.Exp(base, exp, mod)，其中res是已声明的*big.Int变量
sync.Pool复用big.Int必须重置abs缓冲区
sync.Pool 能缓存 *big.Int，但取出后不清理状态，等于喂 GC 垃圾——旧 abs 底层数组仍被引用，无法回收。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- Pool 的
New函数返回对象后，必须显式调用z.Set(nil)或z.SetInt64(0)，否则残留数据会导致计算错误 - 别只清长度：
z.abs = z.abs[:0]不够，Set(nil)才真正释放底层数组引用 - 示例：
var intPool = sync.Pool{New: func() interface{} { return new(big.Int) }}<br>z := intPool.Get().(*big.Int)<br>defer intPool.Put(z.Set(nil)) // 关键：Set(nil)，不是 z = nil - Pool 不适合含指针字段的结构体；
big.Int本身不含指针，是 Pool 的理想候选
Exp/Mod/QuoRem等方法的接收器陷阱
这些方法不返回新对象，而是把结果写入调用者自身（接收器）。传错接收器或覆盖原值，轻则结果错，重则 panic，且掩盖内存问题。
-
z.Exp(x, y, m)：结果写入z，x和y不变；若误写成x.Exp(x, y, m)，x被覆盖，后续所有计算全错 -
q, r := a.QuoRem(b, r)：第三个参数r是余数接收器，商始终返回第一个返回值q，不是r -
Mod对负数向零截断，RSA 中若 padding 后为负，必须先Mod再Exp，顺序反了结果非法 -
m在Exp中为nil表示无模——但加密中绝不能为nil，否则2^65537直接爆内存
固定尺寸大数可预分配abs底层数组
对 RSA 2048、ECC secp256k1 等固定位宽场景，手动预分配 abs 能避免运行时多次扩容，进一步压低 GC 峰值。
- 先估算字长：
cap := (bitLen + 63) / 64（big.Word是 uint64） - 再预分配：
z.abs = make([]big.Word, cap)，之后所有Set/Exp都复用该底层数组 - 注意：这只在位宽高度稳定时有效（如密钥参数），动态长度大数不适用
- 比
sync.Pool更底层——Pool 解决的是对象创建，预分配解决的是内部切片扩容
big.Int 每次调用都在悄悄分配新内存；而最容易被忽略的，是 sync.Pool.Get() 后那一行 z.Set(nil)——漏掉它，复用就变成内存泄漏。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
