本文详解自定义二维向量类中 normalize() 方法因零向量除零而产生 nan 的根本原因，并提供健壮的实现方案、防御性检查及实际应用示例。
本文详解自定义二维向量类中 normalize() 方法因零向量除零而产生 nan 的根本原因，并提供健壮的实现方案、防御性检查及实际应用示例。
在游戏开发（尤其是轻量级平台器或 Metroidvania 模板）中，为避免依赖大型引擎，开发者常自行实现基础数学工具类，如 Vector —— 一个封装 x 和 y 双浮点坐标的结构体，并支持向量运算。其中 normalize() 是关键方法：它将任意非零向量缩放为单位长度（模长为 1），方向不变，广泛用于碰撞响应、朝向计算与位移归一化等场景。
然而，一个常见且隐蔽的陷阱是：当对零向量（即 x == 0 && y == 0）调用 normalize() 时，其内部通常按如下逻辑计算：
public Vector normalize() {
double len = Math.sqrt(x * x + y * y);
return new Vector(x / len, y / len); // ⚠️ 当 len == 0 时，0.0 / 0.0 → NaN
}根据 Java 语言规范（JLS §15.4），任何涉及 NaN 的浮点运算结果均为 NaN；而 0.0 / 0.0 在 IEEE 754 中明确定义为 NaN（非数字）。因此，一旦传入 (0, 0)，返回的 Vector 实例的 x 和 y 将同时变为 NaN，后续所有基于该向量的计算（如位置更新、碰撞检测）均会“感染” NaN，最终导致不可预测的行为（如角色瞬移、逻辑中断）。
✅ 正确做法是始终对零向量做显式防护。推荐两种稳健策略：
方案一：返回安全默认值（推荐用于游戏逻辑）
当向量为零时，返回一个约定的单位向量（如 (1, 0)），避免中断流程：
public Vector normalize() {
double len = Math.sqrt(x * x + y * y);
if (len == 0.0) {
return new Vector(1.0, 0.0); // 或抛出异常，见下文
}
return new Vector(x / len, y / len);
}方案二：抛出语义化异常（推荐用于调试与开发阶段）
明确暴露非法输入，强制调用方处理边界情况：
public Vector normalize() {
double len = Math.sqrt(x * x + y * y);
if (len == 0.0) {
throw new IllegalArgumentException("Cannot normalize zero-length vector");
}
return new Vector(x / len, y / len);
}? 关键注意事项：
- 不要使用 len
- 在碰撞响应逻辑中（如问题描述中的“回退至无碰撞位置”），务必确保输入向量非零：可在调用 normalize() 前添加断言或预检：
Vector displacement = current.sub(last); if (displacement.isZero()) return; // 跳过无效位移 Vector direction = displacement.normalize();
- 使用 Double.isNaN() 进行运行时诊断：在关键节点打印或断言 if (Double.isNaN(v.x) || Double.isNaN(v.y))，快速定位 NaN 源头。
总结：NaN 在向量运算中不是偶然错误，而是零向量未被妥善处理的必然结果。一个生产就绪的 Vector 类必须将 normalize() 视为部分函数（partial function），通过防御性编程明确其定义域（仅限非零向量），并以清晰、一致的方式应对边界情况——这既是代码健壮性的基石，也是游戏逻辑可预测性的保障。
