用平方距离判断球体位置关系最直接：先计算球心平方距离d_sq，再与半径和、差的平方比较，避免开方以提升性能和精度。
用欧氏距离判断球体相对位置最直接
两个三维球体的位置关系完全由球心距离与半径之和、半径之差决定，不需要任何几何库或数值迭代。核心就是算 std::sqrt 后比较，但实际中应避免开方——直接用平方距离更高效且无精度损失。
设球 A 球心为 vec3 a_center，半径 a_radius；球 B 为 vec3 b_center，半径 b_radius。先算平方距离：float d_sq = (a_center - b_center).length_squared()（若用 glm::vec3，对应 glm::length2(a_center - b_center)）。
- 碰撞/相切：当
d_sq == (a_radius + b_radius) * (a_radius + b_radius)（严格相等极少见，工程中建议用 epsilon 容差） - 重叠（相交但非包含）：当
d_sq 且 <code>d_sq > (a_radius - b_radius) * (a_radius - b_radius) - 包含（A 包含 B 或 B 包含 A）：当
d_sq ，注意是 ≤，因为内切也算包含 - 离散（无接触、无重叠）：当
d_sq > (a_radius + b_radius) * (a_radius + b_radius)
为什么不用 std::sqrt？精度和性能都吃亏
开方运算慢，且浮点误差在边界附近会放大。比如两个球刚好外切，理论距离等于半径和，但 std::sqrt(d_sq) 可能略小于或略大于该值，导致误判为“重叠”或“离散”。用平方距离全程整数/浮点运算，逻辑干净，也规避了 sqrt(negative) 风险（虽然球心距离平方不可能负，但防御性编程仍建议先断言 d_sq >= 0）。
- 若必须返回真实距离（如用于物理响应），只在最终需要时调用
std::sqrt，且加if (d_sq > 0.0f) { return std::sqrt(d_sq); }防 NaN - 比较时统一用
float类型，避免double和float混合隐式转换引入意外截断 - 对非常小的球（如半径 ~1e-6）或极大坐标（如中心在 1e9 量级），需警惕浮点有效位丢失——此时可考虑平移坐标系使球心靠近原点再计算
glm::intersect 不提供球-球检测，别白找
GLM 是数学工具库，不是碰撞检测库。glm::intersect 系列函数只覆盖射线-球、射线-平面等基础情形，没有 glm::intersect_sphere_sphere。强行用 glm::distance 本质还是算欧氏距离，内部仍调 std::sqrt，不如自己写平方距离分支逻辑清晰。
立即学习“C++免费学习笔记（深入）”；
- 若项目已用 Bullet 或 PhysX，它们的球体形状（
btSphereShape/physx::PxSphereGeometry）底层也是靠同样距离公式做 broadphase 后的 narrowphase 判定 - 自定义结构体里建议把判定逻辑封装成成员函数，例如
bool Sphere::intersects(const Sphere& other) const，避免每次重复写距离计算 - 注意 C++ 结构体对齐和内存布局：若球体数据要传给 GPU（如用于 compute shader 的粗筛），确保
vec3 center后补 4 字节对齐，或改用glm::vec4存 center（w 置 0）
多个球体批量检测时，别硬套两两 O(n²)
单次两球判定很快，但 1000 个球就要近 50 万次距离计算。这时必须上空间划分——最常用的是均匀网格（uniform grid）或 AABB 树。原理很简单：先把空间划成边长 ≥ 最大球直径的立方格子，每个球只存入其包围盒覆盖的格子索引；检测时只比对同一格子及相邻 26 个格子内的球。
- 网格粒度很关键：太细 → 格子太多，内存暴涨；太粗 → 每个格子塞满球，退化成全量比对
- 若球体半径差异极大（如同时存在 r=0.1 和 r=100 的球），均匀网格失效，应换四叉树（2D）或八叉树（3D）
- 现代做法常结合 SIMD：一次加载 4 组球心坐标，用
__m128并行算 4 个d_sq，再用掩码提取结果——但前提是数据内存对齐且批量连续
边界情况永远比想象中多：球心重合但半径为零、浮点 denormal 数导致 length_squared() 返回非预期小值、跨线程读写球体数据未加锁……这些不写进单元测试，上线后就只能靠日志硬查。
