std::midpoint不能用于物理引擎浮点线性插值，因其底层仍为(a+b)/2、不防溢出、不提精度、不处理NaN/inf、无量级判断；仅在指针分块和整数格点坐标下真正安全。
std::midpoint 不能用于物理引擎的浮点线性插值计算，强行替换 (a + b) / 2 不仅不防溢出、不提精度，反而掩盖数值问题——它只在整数格点坐标或同数组指针分块时真正安全。
std::midpoint(float, float) 是个“假安全”陷阱
物理引擎里位置、速度、加速度几乎全是 float 或 double。此时调用 std::midpoint(a, b) 底层仍走 (a + b) / 2 路径，标准未强制改用更稳健算法。
-
std::midpoint(1e30f, 1.0f)极大概率返回1e30f，因为1e30f + 1.0f == 1e30f（加法丢失低位），而你本意是得到一个相对误差可控的中点 - 它不处理
NaN、inf：若某帧因积分不稳定产生inf，std::midpoint照常传播，不会截断或报错 - 没有量级判断逻辑：不会自动切换到
a + (b - a) * 0.5f或std::fma路径
真正该用的浮点中点方案
当你要在物理引擎中做稳健的位置/速度插值时，必须手动控制数值路径：
- 优先用
std::fma(a, 0.5f, b * 0.5f)（需#include <cmath>）：利用融合乘加指令，减少一次舍入，对量级相近的值更准 - 对量级差异大的情况（如
a = 1e-6f，b = 1e6f），用分支：std::abs(a) >= std::abs(b) ? a + (b - a) * 0.5f : b + (a - b) * 0.5f - 避免写
(a + b) * 0.5f：加法先崩了；a * 0.5f + b * 0.5f同理，两处乘法可能各自下溢
std::midpoint 唯一能用上的物理引擎场景：指针分块
当物理引擎做大规模并行更新（如多线程遍历刚体数组、构建 BVH），需要把连续内存均分给 worker 线程时，std::midpoint 的指针重载才是不可替代的：
立即学习“C++免费学习笔记（深入）”；
-
std::midpoint(begin_ptr, end_ptr)强制要求实现规避end_ptr - begin_ptr超出ptrdiff_t范围的未定义行为——哪怕数组长度逼近地址空间上限 - 手写
begin_ptr + (end_ptr - begin_ptr) / 2中的减法本身可能已溢出，而std::midpoint在标准层面兜底 - 必须确保两个指针指向同一数组（含
one-past-the-end），例如&rigidbodies[0]和&rigidbodies[n]；传std::vector::iterator会编译失败，得先转成原生指针：std::data(v)
整数坐标系下的例外：离散格点物理（如体素引擎）
如果你的物理引擎用 int 表示体素世界坐标、网格索引或离散碰撞盒偏移，那 std::midpoint(int, int) 才真正有用：
- 它保证不溢出：
std::midpoint(INT_MAX, INT_MAX - 1)返回正确结果，而(a + b) / 2是未定义行为 - 必须统一类型如
int32_t，避免混用；头文件是<utility>（C++20），不是<numeric> - 结果向下取整：
std::midpoint(-3, 2)返回-1，不是0，这对格点对齐很关键
最容易被忽略的是：它只保算术过程安全，不校验业务语义——比如传进去两个悬空指针，它也可能“成功”返回一个地址；传进去 pos_a > pos_b 的格点区间，它仍返回数学正确但可能违反物理逻辑的中点。安全边界仅限数值和指针算术本身，不在语义层兜底。
