两个球心距离的平方小于等于两球半径之和的平方时发生碰撞。计算dx、dy、dz后求平方和dist_sq，再与(r1+r2)*(r1+r2)比较，避免开方提升效率。
怎么算两个球心距离
球体碰撞的本质是：两个球心之间的欧几里得距离 ≤ 两球半径之和。所以第一步永远是算 std::sqrt 下的平方和，但别急着开方——多数情况下用平方距离比较更安全高效。
假设球 A 中心为 (x1, y1, z1)、半径 r1，球 B 为 (x2, y2, z2)、半径 r2：
float dx = x2 - x1; float dy = y2 - y1; float dz = z2 - z1; float dist_sq = dx*dx + dy*dy + dz*dz; bool collided = dist_sq <= (r1 + r2) * (r1 + r2);
用平方比较能避免 std::sqrt 的浮点误差和性能开销，尤其在高频检测（如物理引擎循环）中很关键。
浮点精度下怎么避免误判
直接用 == 或 比较浮点结果容易出问题：当两球“刚好相切”时，<code>dist_sq 可能因计算误差略大于理论值，导致漏判。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 加一个极小容差（epsilon），比如
1e-6f，但注意不是加在距离上，而是放宽判定阈值：dist_sq - 更稳妥的做法是用相对误差：若
r1 + r2很大（比如 > 1e4），绝对 epsilon 不够，此时可改用dist_sq - 如果球体坐标来自变换矩阵（如模型空间转世界空间），务必确保输入坐标本身没累积误差——检查是否用了
float而非double做中间计算
要不要用 std::hypot 或 glm::length
不用。前者（std::hypot(x, std::hypot(y, z))）防溢出但慢；后者（如 GLM 库）内部仍是开方，且引入依赖。纯碰撞检测场景，手写三轴差值平方和最直接可控。
例外情况：如果你已经在用 GLM 做向量运算，且项目已统一用 glm::vec3 表达球心，那用 glm::distance 或 glm::length 更一致，但要注意它默认调 std::sqrt —— 仍建议自己取平方：glm::length(ballA.center - ballB.center) → 改成 glm::length2(ballA.center - ballB.center)。
嵌套或运动中的球体怎么处理
静态检测只管“此刻是否相交”。如果球在移动（比如帧间位移大），单次检测会漏掉“穿过彼此”的情况（tunneling）。这时必须做连续碰撞检测（CCD），但那是另一层复杂度：
- 简单保守方案：把半径临时扩大为
r1 + r2 + v_max * dt，其中v_max是两球相对速度模长上限，dt是时间步长 - 真正 CCD 需解一元二次方程，判断线段（球心运动轨迹）到另一球心的距离是否 ≤ 半径和，涉及
std::sqrt和判别式符号判断，容易因数值不稳定返回 NaN - 实践中，除非是高速小球（如子弹、粒子），否则先用扩大半径法兜底，比完整 CCD 更轻量也更鲁棒
真正麻烦的从来不是公式对不对，而是你传进去的 x1、y1……是不是同一坐标系下的值，以及 r1、r2 有没有被缩放或单位混用（比如一个用米，一个用厘米）。这些地方错一点，整个判断就失效，而且很难 debug。
