math.hypot 比 math.sqrt(xx + yy) 更安全，因其通过内部缩放避免大数溢出（如1e200）和小数下溢（如1e-170），保持数值稳定性，但性能略低10–20%。
Math.hypot 为什么比 Math.sqrt(x*x + y*y) 更安全
直接用 Math.hypot(dx, dy) 计算两点距离，核心优势不是“更快”，而是避免中间值溢出或下溢。比如当 dx 或 dy 接近 Number.MAX_VALUE 时，dx * dx 会直接变成 Infinity，导致结果失真；而 Math.hypot 内部做了缩放处理，能保持数值稳定性。
常见错误现象：Math.sqrt(1e200 * 1e200 + 1) 返回 Infinity，但 Math.hypot(1e200, 1) 正确返回约 1e200。
- 仅适用于二维（两个参数）或更高维（多个参数），不支持一维简化写法（如
Math.hypot(x)等价于Math.abs(x)，但通常没人这么用） - 浏览器兼容性良好：Chrome 38+、Firefox 27+、Safari 8+、Edge 12+，Node.js 0.12+ 全支持
- 性能略低于
Math.sqrt(x*x + y*y)（约慢 10–20%），但绝大多数业务场景可忽略
正确传入坐标差，不是原始坐标
Math.hypot 计算的是向量模长，不是点到点距离的封装函数。它不接收两组坐标，只接收一个向量的各分量——也就是先手动算出 dx = x2 - x1、dy = y2 - y1，再传进去。
错误写法：Math.hypot(x1, y1, x2, y2) —— 这算的是原点到四维点 (x1, y1, x2, y2) 的距离，完全偏离需求。
- 正确调用形式固定为：
Math.hypot(x2 - x1, y2 - y1) - 如果涉及整数坐标且追求极致简洁，可省略临时变量，但别为了少写两行牺牲可读性
- 注意浮点误差：即使两点重合（
x1 === x2 && y1 === y2），结果也可能是极小正数（如5e-324），比较距离是否为 0 时建议用Number.EPSILON容差
和手写公式在边界情况下的行为差异
除了大数，小数场景也暴露差异。当 dx 和 dy 都极小（如 1e-170），dx * dx 会下溢为 0，导致 Math.sqrt(0 + 0) 得 0；而 Math.hypot(1e-170, 1e-170) 仍能返回正确数量级的结果（约 1.414e-170）。
- 典型易忽略场景：地理坐标高精度计算、物理引擎微位移、图形抗锯齿偏移量
- 如果明确知道输入范围安全（例如 Canvas 坐标总在 ±10000 内），用
Math.sqrt完全没问题，不必强行替换 - Node.js 中若需计算大量距离且对精度敏感，可配合
BigNumber库，但Math.hypot已覆盖绝大多数 JS 浮点需求
要不要封装成 distance 函数
可以封装，但别加多余抽象。一个干净的工具函数就够了：
const distance = (p1, p2) => Math.hypot(p2.x - p1.x, p2.y - p1.y);
或者更通用一点（兼容数组）：
const distance = ([x1, y1], [x2, y2]) => Math.hypot(x2 - x1, y2 - y1);
- 避免过度设计：不要加类型检查、默认值、单位转换等——这些属于业务逻辑，不该混进基础数学计算
- 如果项目里大量使用，注意命名空间污染风险；纯工具库可用 ES 模块默认导出
- 真正容易被忽略的是：封装后调用栈变深，调试时看到
distance(...)不如直接看Math.hypot(...)直观，尤其对新成员
