如何在屏幕坐标系中正确计算两点间角度并实现精准路径移动

本文详解在y轴向下增长的屏幕坐标系中，使用三角函数计算点间角度的常见误区与修正方案，提供基于向量的稳定路径移动实现，并对比角度法与向量法的工程优劣。

做游戏开发，尤其是2D策略或RPG这类Top-down视角的项目时，经常遇到一个场景：玩家点一下目标位置，角色就得直线匀速跑过去。听起来简单，对吧？但实际动手写代码，问题就来了——明明用 math.Atan2 算了角度，再用 Sin 和 Cos 生成位移，角色却愣是跑偏了，甚至越走越远，完全不往目标点靠拢。

问题到底出在哪？

先说说关键点。屏幕坐标系的Y轴是向下的，这一点和数学课本里的笛卡尔坐标系正好相反。但很多人误以为，这会导致三角函数的计算规则也要跟着变——于是，他们把 Cos 和 Sin 的映射关系颠倒了，以为Y轴向下，Sin 就得对应X，Cos 就得对应Y。结果，方向一乱，角色自然就“飘”了。

实际上，math.Atan2(dy, dx) 返回的弧度，依然遵循标准数学约定：从X轴正方向开始，逆时针递增。也就是说，Cos(θ) 永远对应X轴方向的分量，Sin(θ) 永远对应Y轴方向的分量。这个关系，和屏幕坐标系怎么翻转Y轴，没有半毛钱关系。

原始代码里的写法，就是典型的反面教材：

// ❌ 错误：混淆了cos/sin的坐标映射
X: p.X + math.Sin(v.Radians)*v.Distance,  // Sin 给了 X → 错！
Y: p.Y + math.Cos(v.Radians)*v.Distance,  // Cos 给了 Y → 错！

正确的做法，其实很简单，数学上怎么定义，代码就怎么写：

// ✅ 正确：cos→X, sin→Y（无论Y轴朝向）
func (p *Position) Add(v *Vector) *Position {
    return &Position{
        X: p.X + math.Cos(v.Radians)*v.Distance,
        Y: p.Y + math.Sin(v.Radians)*v.Distance,
    }
}

但是，话说回来，角度法本身就有不少“坑”：象限判断、PI翻转、角度归一化……你写一次，可能就踩一次雷。所以，更推荐的做法，是彻底绕过角度计算，直接上向量。

为什么？因为向量法天然适配屏幕坐标系——dy = target.Y - current.Y 为正，角色就向下移动；为负，就向上。逻辑清晰，数值稳定，性能也不差。而且，它从根本上避免了三角函数调用带来的精度损失和开销。

向量法的实现，大概是这个样子：

type Vector struct {
    dX, dY float64 // 直接存储单位方向 × 速度
}

func CreatePathVector(pos1, pos2 *Position, speed int) *Vector {
    dx := pos2.X - pos1.X
    dy := pos2.Y - pos1.Y
    mag := math.Sqrt(dx*dx + dy*dy)
    if mag == 0 {
        return &Vector{0, 0} // 防止除零
    }
    scale := float64(speed) / mag
    return &Vector{
        dX: dx * scale,
        dY: dy * scale,
    }
}

func (p *Position) Add(v *Vector) *Position {
    return &Position{X: p.X + v.dX, Y: p.Y + v.dY}
}

实际跑起来，几步之后，角色就会严格沿着直线逼近目标。误差？也就浮点运算累积的那点，定期重校准一下，或者到终点附近直接吸附，就完美搞定。

必须警惕的是几个细节：

• 算向量模长 mag 时，一定要检查是否为零，不然除零崩溃会让你怀疑人生；
• 如果需要“减速停靠”，可以在距离目标小于某个阈值时，动态缩放速度值；
• 角度法也不是完全没用——比如你要旋转精灵的朝向（坦克炮塔、角色面朝方向），这时候还是得靠角度。但移动逻辑，请务必交给向量；
• 如果非要用 math.Atan2，记住参数顺序是 Atan2(dy, dx)，别写反了。它自动处理象限和边界，比 Atan(dy/dx) 靠谱得多。

总结一下：在屏幕坐标系里算角度，关键不是“适配Y轴反转”，而是坚守 Cos→X, Sin→Y 的数学本质。但真正工程实践里，绕过角度、直操作向量，才是那个鲁棒、高效、可维护的正解。