应比较距离平方与半径平方，避免调用 std::sqrt；即判断 dxdx + dydy + dzdz <= rr，而非 std::sqrt(dxdx + dydy + dz*dz) <= r。
用 std::sqrt 和距离平方比较，别直接开方
判断点是否在球内，本质是看该点到球心的欧氏距离是否小于等于半径。但实际写代码时，std::sqrt 是相对昂贵的操作，尤其在高频调用（比如光线追踪、粒子碰撞检测）中。更稳妥的做法是**比较距离的平方与半径的平方**，完全避开浮点开方。
常见错误是写成：std::sqrt(dx*dx + dy*dy + dz*dz) —— 这在数值上等价，但多了一次开方，还可能引入额外浮点误差（特别是 <code>r 本身是 float 类型时）。
- 正确做法：计算
dx*dx + dy*dy + dz*dz - 注意
r若为负数，应提前校验；球体定义要求r >= 0，否则无意义 - 若点坐标和半径类型混用（如
double点 +float半径），隐式转换可能导致精度丢失，建议统一为double或使用模板推导
glm::length 在 OpenGL 项目里怎么用才不慢
如果你用 glm 库（比如做图形渲染），别下意识调 glm::length(vec) 判断球内——它内部就是调 std::sqrt，和手写一样有开方开销。
应该用 glm::length2，它返回向量模的平方，直接对应距离平方：
立即学习“C++免费学习笔记（深入）”；
glm::vec3 p = /* 点 */; glm::vec3 center = /* 球心 */; float r = /* 半径 */; float distSq = glm::length2(p - center); bool inside = distSq <= r * r;
注意：glm::length2 对 vec3、vec4 都有效，但不会自动处理 r 的符号；仍需确保 r >= 0，否则逻辑错乱。
- 若
r是double，而p是glm::vec3（默认float），乘法会降精度，建议显式用glm::dvec3或 cast -
glm::distance(p, center)同样含开方，不要用它做判据
边界情况：点刚好在球面上，浮点误差怎么防
当 distSq 与 r*r 极其接近时（比如因坐标或半径是 float 导致舍入），直接用 可能因误差误判。这不是理论问题，而是真实发生过的 bug，尤其在网格顶点贴合球面建模时。
解决方案不是加容差（epsilon）那么简单——容差大小依赖量纲，盲目设 1e-6f 在单位是千米的场景下就失效了。
- 推荐用相对容差：
distSq ::epsilon()) - 更稳妥的是：若业务允许，把“球面”视为“包含边界”的闭集，且所有输入数据本身已做合理归一化（如坐标缩放到 [0,1]），那直接
就够用 - 绝对不要用
==判断是否在球面上——那是另一个问题，且几乎总错
要不要封装成函数？模板参数怎么选
如果多个地方用，封装成函数确实值得，但别图省事写死 float。C++ 模板能自动适配，但要注意两个关键点：
template<typename T>
bool is_inside_sphere(const T x, const T y, const T z,
const T cx, const T cy, const T cz,
const T r) {
if (r < T(0)) return false;
T dx = x - cx, dy = y - cy, dz = z - cz;
return dx*dx + dy*dy + dz*dz <= r*r;
}这个函数支持 float、double、甚至 long double，但前提是所有参数类型一致。混合传参（比如 double x + float r）会触发隐式转换，可能损失精度。
- 若坐标来自
glm::vec3，建议另写一个重载版本，接受const glm::tvec3<t>&</t>，避免拆包开销 - 不建议加
constexpr——除非确定所有输入都是编译期常量，否则编译器无法优化掉运行时分支 - 函数内不做异常抛出，球半径为负直接返回
false更符合几何直觉
浮点类型选择、距离平方比较、边界容差处理——这三处稍不留意，就会让“简单判断”在大规模数据或高精度场景下出问题。
