math.sqrt不是最快的浮点平方根，因其采用ieee 754兼容的通用实现（查表+牛顿迭代+异常处理），而近似算法可通过位运算（如float64bits右移+微调）加速，适用于允许±1%误差的高频数值场景。
为什么 math.Sqrt 不是最快的浮点平方根？
Go 标准库的 math.Sqrt 是 IEEE 754 兼容、全精度、跨平台安全的实现，但它走的是通用路径：查表 + 牛顿迭代 + 异常处理。如果你在图形计算、物理模拟或高频数值循环里反复调用它，这部分开销会累积——尤其当你能接受 ±1% 误差时，完全没必要为每个数都保证 ULP=0.5。
用 math.Float64bits + 位运算手撕近似 sqrt
IEEE 754 双精度浮点数的指数域（11 位）和尾数域（52 位）结构，使得对数近似可转为位移与加法。核心思路：利用 log2(x) ≈ exponent + log2(1+mantissa)，而 sqrt(x) = 2^(log2(x)/2)，所以只需把原数的 bit 表示右移 1 位再微调。
常见错误现象：math.Float64bits(0.0) 返回 0，但直接右移会错失符号位；负数输入不处理会返回非预期大正数；NaN 和 Inf 未过滤会导致传播错误。
- 只对正有限数生效，开头加
if x 快速兜底 - 用
math.Float64bits(x)拿到 uint64，右移 1 位后加一个 magic bias（常用0x1FF8000000000000）来补偿尾数非线性 - 再用
math.Float64frombits转回 float64，通常误差在 0.1%～0.5% 之间 - 如需收敛，可接 1 轮牛顿迭代：
y = y * (1.5 - x * 0.5 * y * y)
runtime/internal/math 里的 sqrt 汇编实现能直接用吗？
不能。Go 运行时内部在 runtime/internal/math 下有针对 amd64/arm64 的 sqrt 汇编函数（如 sqrt_fast），但它们是 unexported、无文档、不保证 ABI 稳定的内部符号，链接时会被 Go 工具链 strip 或重命名。强行 //go:linkname 调用风险极高：升级 Go 版本后可能 panic，且无法跨 GOOS/GOARCH 移植。
立即学习“go语言免费学习笔记（深入）”；
真正可用的底层加速路径只有两条：
- 启用
-gcflags="-l" -ldflags="-s -w"减少干扰，让math.Sqrt更容易被 CPU 的sqrtss/sqrtsd指令直译（现代 x86_64 上它其实已经很快） - 自己写
//go:asm并用GOAMD64=v4启用 AVX 指令集，调用vsqrtsd—— 但这就脱离了“纯 Go”范畴，得维护多份 asm 文件
什么时候该坚持用 math.Sqrt？
绝大多数情况就该用它。它的“慢”是相对的：在非 tight loop 场景下，函数调用开销远小于你省下的那几个纳秒；它正确处理所有边界值（包括 subnormal 数），而手写位运算版本在 x 时会彻底失效；而且 Go 1.22+ 对 <code>math.Sqrt 做了 inline 优化，在简单表达式中（如 y := math.Sqrt(x*x + z*z)）几乎零成本。
真正值得替换的场景非常窄：每秒调用 >10⁷ 次、输入范围可控（如 [0.01, 1000]）、允许相对误差 >0.1%、且 profiling 明确指出 math.Sqrt 是热点。
别为了“底层优化”提前抽象一个 FastSqrt 接口——等 pprof 打出火焰图再说。浮点数的坑不在速度，在语义一致性。
