big.Int 运算必须调用方法而非操作符，初始化须用 SetString，负数模运算结果可能为负，JSON/数据库需手动处理，避免 Int64() 中转和未清零的 sync.Pool 复用。
big.Int 不能用 +、-、*、/，必须调方法
Go 的 *big.Int 是结构体指针，不是基础类型，编译器根本不认识 a + b 这种写法——会直接报错：invalid operation: a + b (operator + not defined on *big.Int)。
所有运算都得走方法：用 a.Add(a, b) 代替 a + b，a.Mul(a, b) 代替 a * b，依此类推。这些方法返回的是接收者本身（也就是第一个参数），方便链式调用，但本质是就地修改。
- 别写
c := a.Add(a, b)然后还指望a没变——它已经被改成a + b了 - 要保留原值？先拷贝：
tmp := new(big.Int).Set(a)，再对tmp操作 - 想链式调用又不污染原变量？把目标变量单独声明：
res := new(big.Int).Add(a, b).Mul(c, d)，前提是res是新实例
SetString 是唯一安全的超大数初始化方式
别碰 big.NewInt(999999999999999999999)——这行代码连编译都过不去，因为字面量早已超出 int64 范围，编译器先报错。
正确路径只有一条：字符串解析。用 new(big.Int).SetString("12345678901234567890", 10)，第二个参数是进制（10 表示十进制）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 十六进制哈希值？去掉
"0x"前缀，显式传16：i.SetString("a1b2c3", 16) - 字符串带空格或换行？
SetString静默失败，返回nil, false；务必检查第二个返回值：if ok := i.SetString(s, 10); !ok { /* 解析失败 */ } - 别用
strconv.ParseInt或fmt.Sscanf中转——它们照样卡在int64上，信息早就丢了
Div 和 Mod 对负数的行为和原生 /、% 不一样
Go 原生整数除法向零截断，-7 / 3 是 -2，-7 % 3 是 -1；big.Int.Div 和 big.Int.Mod 也遵循这个规则，但新手常误以为它像数学模运算（结果非负）。
比如：new(big.Int).Mod(new(big.Int).SetInt64(-7), new(big.Int).SetInt64(3)) 结果是 -1，不是 2。如果真需要非负余数，得手动调整：if r.Sign() == -1 { r.Add(r, m) }（m 是模数）。
-
Div和Mod遇到除数为 0 会直接panic，没有错误返回，调用前必须检查：if m.Sign() == 0 { /* 处理零除 */ } - 要同时拿到商和余数？用
QuoRem，比分开调Div+Mod更高效、更一致
JSON 序列化不支持 *big.Int，必须自己实现
直接 json.Marshal(struct{ X *big.Int }) 会得到 {"X":{}} 或 panic，因为 *big.Int 没实现 json.Marshaler 接口。
标准解法是包装一层，实现 MarshalJSON 返回字符串，UnmarshalJSON 用 SetString 解析：
type BigInt struct {
*big.Int
}
func (b BigInt) MarshalJSON() ([]byte, error) {
if b.Int == nil {
return []byte("null"), nil
}
return []byte(`"` + b.String() + `"`), nil
}
func (b *BigInt) UnmarshalJSON(data []byte) error {
s := strings.Trim(string(data), `"`)
_, ok := b.SetInt64(0).SetString(s, 10)
if !ok {
return fmt.Errorf("invalid big.Int string: %s", s)
}
return nil
}- 数据库场景同理：字段类型用
TEXT，读写时走.String()和.SetString(s, 10) - 别用
Int64()当中转——一旦值超过9223372036854775807，就永远回不来了
最常被忽略的其实是复用：循环里反复 new(big.Int) 看似干净，实则 GC 压力陡增；一个没清零的 sync.Pool 里的 *big.Int 可能带着上一次的高位数据继续参与计算——得手动 Set(nil) 或 SetInt64(0)。
