Int.Mul 不能链式调用阶乘，因其就地修改并返回接收者，导致中间结果被覆盖；正确做法是用临时变量承接或明确赋值顺序，并显式初始化 res。
为什么 math/big 的 Int.Mul 不能直接链式调用阶乘
因为 Int.Mul 是就地修改（in-place），返回的是接收者本身，不是新对象。直接写 res.Mul(res, i).Mul(...) 会把中间结果反复覆盖，最后算错。
- 正确做法是用一个临时变量承接每次乘法结果，或复用同一
*big.Int实例但明确赋值顺序 - 常见错误现象：
10!算出来是负数或远小于预期——大概率是误用了链式调用或没初始化res - 初始化必须显式：用
new(big.Int).SetInt64(1)或big.NewInt(1)，不能只写var res *big.Int（此时为 nil）
怎么写一个安全、可读的 big.Int 阶乘函数
核心是控制变量生命周期和避免重复分配。别在循环里反复 new(big.Int)，也别依赖隐式类型转换。
- 输入校验要前置：
n 直接 panic 或返回 error，<code>big.Int不处理负数阶乘 - 用
big.Int.Set复用对象比新建更省内存，尤其计算1000!这种大数时明显 - 循环中用
i := big.NewInt(int64(j))构造当前乘数，别用int64混合运算——res.Mul(res, &i)会报类型错 - 示例片段：
func factorial(n int64) *big.Int { if n < 0 { panic("factorial: negative input") } res := big.NewInt(1) tmp := new(big.Int) for i := int64(2); i <= n; i++ { tmp.SetInt64(i) res.Mul(res, tmp) } return res }
big.Int 阶乘性能瓶颈在哪？什么时候该换方案
不是算法复杂度问题（O(n) 乘法不可避免），而是每次 Mul 内部要做大数乘法的 Karatsuba 或朴素算法切换，以及内存拷贝开销。
- 计算
10000!时，res会增长到约 36KB，后续每次乘法都要复制这么大的底层数组 - 如果只是需要最后几位数字（比如末尾零个数），别硬算完整阶乘——用公式
floor(n/5) + floor(n/25) + ... - 若需频繁计算不同
n的阶乘，考虑缓存小值（如n ≤ 1000）的结果，避免重复运算 - Go 1.21+ 中
big.Int的乘法已有优化，但依然不建议在 hot path 里算超大阶乘（如n > 1e5）
容易被忽略的边界：零值、并发、字符串输出
big.Int 的零值是 &big.Int{}，但未初始化的指针是 nil，一调 Mul 就 panic；另外它不是并发安全的。
立即学习“go语言免费学习笔记（深入）”；
-
factorial(0)必须返回big.NewInt(1)，数学定义如此，别漏掉这个 case - 多个 goroutine 共享同一个
*big.Int实例并调Mul？不行，会数据竞争——每个 goroutine 应该有自己的实例 - 转字符串用
res.String()即可，但超长结果（如10^5!）会导致大量内存分配，必要时用res.Text(base)控制进制，或流式写入io.Writer - 调试时别用
fmt.Printf("%v", res)打印超大数——终端卡死，改用fmt.Printf("%s", res.String()[:min(100, len(res.String()))])
big.Int，或者根本不用算。 
