std::midpoint仅对同类型有符号/无符号整数及同数组指针防溢出，不适用于浮点插值或物理引擎通用中点计算；其指针重载是大数组分块唯一安全方案，但不校验内存有效性。
在物理引擎中直接用 (a + b) / 2 算位置/速度中点，当物体坐标接近 INT_MAX 或 SIZE_MAX（比如超大世界坐标、长时间累积位移）时，加法溢出会导致位置突变、碰撞检测失效甚至模拟崩溃；std::midpoint 能防整数溢出，但**仅对同类型有符号整数、无符号整数或同数组指针真正有效，对浮点数不防溢出也不提精度，且物理引擎里多数场景根本不能用它替代插值逻辑**。
std::midpoint(int, int) 在整数坐标系下的安全边界
物理引擎若用 int 表示离散格点坐标（如体素世界、网格化刚体），std::midpoint 是目前唯一标准保证不溢出的中点计算方式：
- 必须两个参数为同一有符号整型，例如
std::midpoint(pos_a, pos_b)中pos_a和pos_b都是int，传int和long会编译失败 - 结果是向下取整中点：
std::midpoint(-3, 2)返回-1，不是0，这对碰撞盒对齐、格点判定是关键语义 - 支持负数、跨零区间，无需额外分支判断符号；但若
pos_b （如反向区间），结果仍数学正确，业务层需自行校验是否允许该方向 - 不接受表达式本身已溢出的输入：比如
std::midpoint(x, y + 1)中y + 1先溢出，则std::midpoint不兜底——它只保自身算术过程安全
float/double 位置插值千万别用 std::midpoint
物理引擎绝大多数位置、速度、加速度使用 float 或 double，此时调用 std::midpoint(a, b) **等价于 (a + b) / 2，不规避溢出，也不改善精度，反而掩盖问题**：
-
std::midpoint(1e30f, 1.0f)极大概率返回1e30f，因为1e30f + 1.0f == 1e30f，加法丢失低位，而手写a + (b - a) * 0.5f至少保留相对误差可控 - 没有 NaN/inf 特殊处理，和裸算一样传播异常值；若某帧位置因数值不稳定产生
inf，std::midpoint会照常返回inf，不会报错或截断 - 真正需要稳健浮点中点时，应优先用
std::fma(a, 0.5f, b * 0.5f)（需#include <cmath>），或根据量级分支：std::abs(a) >= std::abs(b) ? a + (b - a) * 0.5f : b + (a - b) * 0.5f
指针中点：物理引擎内存布局切分的唯一安全出口
当物理引擎做大规模并行处理（如多线程更新刚体列表、BVH 构建），需把连续内存块均分给 worker 线程时，std::midpoint 的指针重载是**不可替代的**：
立即学习“C++免费学习笔记（深入）”；
-
std::midpoint(begin_ptr, end_ptr)明确要求实现规避end_ptr - begin_ptr超出ptrdiff_t范围的未定义行为，哪怕数组长度逼近SIZE_MAX / sizeof(RigidBody)也安全 - 必须是同一分配块内的原生指针：
std::midpoint(&list[0], &list[N])合法，std::midpoint(ptr1, ptr2)若来自不同new或malloc块则未定义 - 不接受
std::vector::iterator、std::unique_ptr<T[]>::get()等非原生指针；得用std::data(list)或显式取址 - 它不检查
begin_ptr是否有效、end_ptr是否越界——越界访问仍是 UB，它只保“算出来的地址在数值上合法”
为什么你不能把 std::midpoint 当作通用插值工具
物理引擎里的“中点”往往不是纯数学中点，而是带权重、带时间步长、需保持守恒律的插值，std::midpoint 完全不覆盖这些：
- 它不支持三元插值（如
lerp(a, b, t)），更不支持t非 0.5 的情况；想做亚像素位置预测？得用std::lerp，不是std::midpoint - 它不处理类型提升：传
short返回short，不会自动升到int，若后续参与更大范围运算，可能隐含截断风险 - 它不校验区间有效性：传
std::midpoint(p, p)返回p，但若p是悬空指针，结果仍是非法地址——它只做算术，不管内存 - 最常被忽略的一点：它解决的是“计算过程不崩”，不是“结果物理合理”。坐标溢出可能是世界尺寸设计缺陷，而非单纯换一个函数就能掩盖。
