std::midpoint是唯一标准层面保证整型算术安全的插值方案，但仅适用于同类型有符号整型或同数组指针，浮点插值不适用；需统一类型如int32_t，避免混用；不处理NaN/inf，且不保证语义正确性。
在物理引擎中对物体位置、速度等离散坐标做插值时，直接写 (a + b) / 2 极易因坐标值极大（如天文模拟、大世界坐标偏移）触发有符号整数溢出，std::midpoint 是唯一能从标准层面保证算术安全的替代方案——但仅当用于同类型整型或同数组指针时成立，浮点插值反而是坑。
std::midpoint(int, int) 在网格坐标插值中必须用，且要统一符号和类型
物理引擎常把世界坐标映射到整型网格索引（如 voxel 索引、tile ID），此时 a 和 b 可能是 int32_t 量级的正负大数。例如 a = INT_MAX - 5, b = INT_MAX，(a + b) / 2 中加法就 UB。
- 必须确保两个参数为**完全相同有符号整型**：
std::midpoint(x, y)要求x和y都是int32_t或都显式转成int64_t；传int和long混用会编译失败 - 不强制要求
a ，<code>std::midpoint(100, -10)返回45，数学正确，但你要确认插值方向是否符合物理逻辑（比如碰撞检测中区间翻转可能意味着无效输入） - 结果向下取整：
std::midpoint(-3, 2)返回-1，不是0，这对格点对齐很关键，别误以为是四舍五入 - 头文件是
<utility>（C++20），不是<numeric>——错包含会导致编译器找不到函数
std::midpoint(T*, T*) 是大世界指针插值不可替代的写法
当物理引擎用大数组缓存刚体数据（如 Body* pool = new Body[SIZE_MAX / sizeof(Body) + 1]），计算中间地址时，pool + (end - pool) / 2 中的 end - pool 可能超出 ptrdiff_t 范围，直接 UB；std::midpoint(pool, end) 是标准唯一保证不崩的路径。
- 两个指针必须指向**同一数组或 one-past-the-end**：
std::midpoint(&v[0], &v[0] + v.size())合法，但std::midpoint(v.data(), u.data())（不同容器）未定义 - 不接受
std::vector::iterator：必须用原生指针，&v[0]或std::data(v)转换后才能传 -
const Body*和Body*类型不匹配，不能混用——这其实是好事，强制你在编译期暴露 const 正确性问题 - 它不检查指针是否有效：传两个悬空指针，它仍可能“成功”返回一个地址，内存安全得你兜底
float/double 插值千万别用 std::midpoint
物理引擎里位置、速度常用 float 表示，但 std::midpoint(1e30f, 1.0f) 底层仍是 (a + b) / 2，1e30f + 1.0f == 1e30f，结果丢失精度；而手写 a + (b - a) * 0.5f 或 std::fma(a, 0.5f, b * 0.5f) 更稳。
立即学习“C++免费学习笔记（深入）”；
-
std::midpoint(float, float)编译通过，但只是语法合法，无实际防溢出/抗精度坍塌能力 - 若
a和b符号相反且量级差大（如1e30f和-1e-6f），std::midpoint仍可能因加法舍入丢掉小量贡献 - 真正需要稳健浮点中点时，优先分支判断：
std::abs(a) >= std::abs(b) ? a + (b - a) * 0.5f : b + (a - b) * 0.5f - NaN 和 inf 不被特殊处理，和裸算一样传播——插值前你自己得校验输入有效性
最容易被忽略的是：它只保“数值算得对”，不保“语义用得对”。比如二分查找中用 std::midpoint(low, high) 得到索引后，仍需检查该索引是否在合法范围内；传进去两个越界指针，它照样算，结果毫无意义。安全边界只划在算术层，不在业务逻辑层。
