使用 sqrt 前必须包含 ，否则编译报错；它位于 std 命名空间，有多个重载版本；对负数调用行为未定义；整数开方需防精度误差和溢出；性能敏感场景应避免不必要的 sqrt。
用 sqrt 前必须包含 <cmath></cmath>
不加头文件会导致编译失败，错误信息通常是 ‘sqrt’ was not declared in this scope。C++ 标准库中 sqrt 不在 <math.h></math.h>（C 风格头文件）里直接可用，也不在全局命名空间无条件暴露——它定义在 <cmath></cmath> 中，且通常位于 std 命名空间下。
正确写法：
#include <cmath> double x = std::sqrt(16.0); // 推荐显式写 std:: // 或 using std::sqrt; 再调用 sqrt(16.0)
-
sqrt有多个重载版本：float sqrtf(float)、double sqrt(double)、long double sqrtl(long double)，传入整数（如int）会隐式转为double，但可能损失精度或触发警告 - 对负数调用
sqrt的行为是未定义的（多数平台返回NaN，且可能触发浮点异常） - 不要用
using namespace std;来“省事”，尤其在头文件或大型项目中，容易引发命名冲突
整数开方要防溢出和精度陷阱
如果目标是求整数 n 的整数平方根（即最大的整数 k 满足 k*k ≤ n），直接用 static_cast<int>(std::sqrt(n))</int> 很危险。
- 浮点计算存在舍入误差，例如
std::sqrt(25) + 1e-15可能被截断为5，但std::sqrt(9999999999999999ULL)在double下可能无法精确表示，导致向下取整错位 - 对大整数（如
uint64_t），double只有 53 位有效精度，无法准确表示所有 64 位整数，sqrt结果可能偏小或偏大 1 - 更稳妥的做法是：先用
sqrt得到近似值，再用整数上下调整验证，例如k = static_cast<long long>(std::sqrt(n));</long>后检查(k+1)*(k+1) 或 <code>k*k > n并修正
性能敏感场景慎用 sqrt，考虑替代方案
在高频循环（如图形渲染、物理模拟）中，sqrt 是相对昂贵的操作，尤其当只需要比较大小（如距离判别）时，完全可避免开方。
立即学习“C++免费学习笔记（深入）”；
- 判断点是否在圆内？用
dx*dx + dy*dy ，而不是 <code>std::sqrt(dx*dx + dy*dy) - 需要单位向量？先算平方模长
len2 = x*x + y*y，若非零再除以std::sqrt(len2)；若只是归一化方向，且后续只参与点积等运算，有时可延后开方甚至用倒数平方根近似（如_mm_rsqrt_ss指令） - 编译器一般不会自动把
a*a == b*b优化成abs(a) == abs(b)，但会识别x*x + y*y 这类模式并保留为整数/浮点运算
sqrt 对 NaN 和无穷大的行为是标准定义的
这是容易被忽略但影响鲁棒性的点：C++ 标准（基于 IEEE 754）规定了这些边界输入的输出。
-
std::sqrt(NAN)返回NAN -
std::sqrt(+INFINITY)也返回+INFINITY -
std::sqrt(-INFINITY)或负有限数 → 返回NAN，并可能设置errno = EDOM（取决于实现和编译选项） - 若需检测失败，可配合
std::isnan或errno（注意多线程下errno不安全），但更推荐前置校验输入范围
真正麻烦的是那些看起来合法、实则因中间计算溢出变成 INF 或 NaN 的表达式，比如对极大浮点数先平方再开方——这时候 sqrt 已经救不回精度了。
