math.Sqrt 无法控制精度，因其基于 CPU 硬件指令，返回 IEEE-754 double 最佳逼近值，仅约15~17位有效数字；需高精度时应使用 math/big 结合整数缩放与逐位减法或牛顿迭代。
math.Sqrt 本身不提供精度控制接口，它返回的是 float64 范围内最接近的 IEEE-754 双精度近似值——你无法通过参数指定“保留 10 位小数”或“误差小于 1e-20”。真要控精度，得换路子。
为什么 math.Sqrt 不能设精度
math.Sqrt 是硬件指令级实现（如 sqrtsd），直接映射 CPU 的浮点开方单元。它的输出是单个 float64 值，精度上限由 IEEE-754 定义（约 15~17 位十进制有效数字），不存在“多算几位再截断”的机制。
常见误解：
- 误以为
math.Sqrt(2.0)返回的是精确 √2 —— 实际是它在float64表示能力内的最佳逼近 - 试图用
fmt.Printf("%.50f", math.Sqrt(2))看高精度 —— 后面全是无效补零，不是真实精度 - 对结果做
math.Round(x*1e10)/1e10就当“控制了精度” —— 这只是显示/截断，不提升计算过程精度
需要 50 位小数精度？用 math/big + 逐位减法
标准库不支持，但 math/big 提供了任意精度整数运算基础。要算 50 位小数的 √2，核心思路是：把原数放大成整数（比如乘以 10¹⁰⁰），然后对这个大整数开方（得到整数结果），最后再缩回小数点位置。
立即学习“go语言免费学习笔记（深入）”；
关键步骤：
- 输入字符串
"2.0"→ 解析为*big.Rat或手动转成整数倍数（避免float64中间转换失真） - 将数值 × 10(2×prec)（prec=50，则乘 10¹⁰⁰），得到一个大整数
N - 用改进的逐位减法法（非牛顿迭代）求
*big.Int版本的 √N —— 每步严格生成一位十进制数字，无累积误差 - 结果再除以 10prec（即右移小数点 50 位），得到高精度小数表示
注意：*big.Rat.Sqrt() 不存在；*big.Rat.SetFloat64() 会先过 float64，直接报废精度。
想控误差范围？用牛顿迭代自己写 sqrt
如果你不需要固定小数位，而是要求“结果与真实值之差
x_{n+1} = (x_n + S/x_n) / 2
实操要点：
- 初值选
max(1.0, S)或用bits.Len64(uint64(S))估算量级，收敛更快 - 停止条件别用
abs(x_{n+1} - x_n) —— 在极小值附近可能震荡，改用 <code>abs(x_n*x_n - S) （相对误差） - 迭代 6~8 次通常够
float64精度；若用*big.Float，可设Accuray字段控制内部精度 - 务必加最大迭代次数限制，防止 S == 0 或初始值为 0 导致除零
整数开方要精确结果？别碰 float64
比如求 uint64(1 的 floor(√x)，用 <code>int(math.Sqrt(float64(x))) 会错——因为 float64 只能精确表示 ≤ 2⁵³ 的整数，超了就丢位。
安全做法：
- 对
uint64：用二分查找，范围是[0, x>>31+1]，每次算mid*mid （注意溢出，用 <code>big.Int或检查mid > x/mid） - 或用牛顿迭代配合
big.Int，公式改为整数版：next = (cur + x/cur) / 2，全部用*big.Int运算 -
math/bits的Len64(x)可快速给出初值位宽，减少迭代轮数
真正容易被忽略的点：精度需求和数据来源必须对齐。用户输了个 "1.2345678901234567890" 字符串，你却用 strconv.ParseFloat(s, 64) 先转成 float64——这一步已经把后 10 位全弄丢了，后面再怎么“控精度”都是徒劳。
