1. 项目概述：从A*到更优的寻路方案

如果你正在开发一款Unity游戏，尤其是带有复杂地图、大量动态单位（比如RTS、MOBA、SLG）或者对移动端性能有苛刻要求的项目，那么“寻路”这个功能大概率是你性能优化清单上的重点关照对象。很多开发者，尤其是刚入行不久的朋友，一提到寻路，脑子里蹦出来的第一个词就是A*（A-Star）。这没错，A*算法确实是寻路领域的基石，它可靠、通用、易于理解，网上教程一抓一大把，在Unity里用NavMesh或者自己写个网格（Grid）实现起来也不难。

但问题恰恰出在这里——“够用”不等于“好用”。当你的游戏地图从100x100的小格子变成1000x1000甚至更大的开放世界，当你的同屏单位从几个、几十个变成成百上千个时，原生的A算法就会迅速成为性能瓶颈。你会发现CPU时间被大量消耗在“开启列表”（Open List）的排序和节点（Node）的反复评估上，帧率开始波动，玩家操作出现延迟。这时候，如果你还只会用基础的A，面对性能压力可能会感到束手无策。

这就是我们今天要深入探讨的核心：在Unity项目中，如何用JPS（Jump Point Search）和HPA（Hierarchical Pathfinding A）这两种进阶算法，来系统性地优化你的寻路性能。** 这不仅仅是替换一个算法那么简单，它涉及到对寻路问题本质的重新思考，以及对不同场景下性能与效果权衡的深度理解。A是你的瑞士军刀，而JPS和HPA则是为特定任务量身打造的专业工具，用对了地方，效率提升是数量级的。

简单来说，A是“逐格搜索”，JPS是“跳点搜索”，而HPA是“分层抽象搜索”。它们的目标一致：找到从A点到B点的最短（或较优）路径。但实现方式和适用场景截然不同。掌握它们，意味着你能为你的游戏选择最合适的“寻路引擎”，而不是让所有场景都去将就一个通用方案。

2. 寻路算法核心原理与选型逻辑

在深入代码之前，我们必须先搞清楚这几个算法到底在干什么，以及为什么在某些场景下A*会“力不从心”。理解原理是正确选型和优化的前提。

2.1 A*算法的瓶颈在哪里？

A*算法之所以经典，是因为它结合了Dijkstra算法的完备性和贪婪最佳优先搜索的效率。它通过一个评估函数f(n) = g(n) + h(n)来指导搜索方向，其中g(n)是从起点到当前节点n的实际代价，h(n)是从当前节点n到终点的预估代价（启发值）。

在Unity中，我们通常用一个二维网格（Grid）来表示可行走区域。A*会从起点开始，检查其上下左右、左上、右上、左下、右下（八方向）或仅上下左右（四方向）的相邻格子。如果格子可行走，就将其加入“开启列表”，并计算f值。然后从开启列表中取出f值最小的节点进行扩展，如此循环，直到找到终点。

它的性能瓶颈主要源于两点：

1. 节点扩展数量庞大：在空旷或复杂区域，A*会像水波纹一样扩散，检查大量不必要的节点。即使有启发函数h(n)引导，它仍然需要逐个评估许多“看起来方向对，但实际并非关键路径”的节点。
2. 开启列表的维护开销：随着搜索的进行，开启列表可能包含成千上万个节点。每次从中取出最小f值节点，都需要进行排序或使用优先队列（如Binary Heap），这个操作的时间复杂度是O(log N)。当N很大时，开销显著。

注意：Unity自带的NavMesh系统底层也使用了A*的变种，但它是在导航网格（由凸多边形构成）上运行的，相比均匀网格已经优化了很多。然而，对于超大规模动态网格，或者需要极高频寻路请求的场景（如千人同屏的SLG），NavMesh的生成和更新成本以及单次寻路开销可能依然过高。

2.2 JPS（Jump Point Search）：为均匀网格而生的“直线加速器”

JPS，中文常称作“跳点搜索”，它不是一个全新的算法，而是A*在均匀网格（Uniform Grid）上的一个极致优化。它的核心思想非常巧妙：跳过那些在路径对称性上冗余的节点，直接“跳”到路径上的关键决策点——跳点（Jump Point）。

想象一下在一个空旷的矩形房间里，从一角走到对角。用A*，你会检查沿着对角线方向的每一个格子。但用JPS，它识别出这是一条无障碍的直线，于是它不会逐个检查，而是通过一种称为“跳跃”（Jumping）的规则，直接“看”到这条直线的终点（或第一个障碍物），将其作为一个节点。这个“跳跃”的过程，本质上是通过递归或迭代，沿着直线方向快速扫描，直到碰到障碍物、地图边界或者一个“跳点”。

什么是跳点？简单说，就是路径方向可能发生改变的点。JPS定义了一套严格的规则来识别跳点：

• 强迫邻居（Forced Neighbour）：如果一个节点n的某个邻居，从n的父节点过来无法在不经过障碍物的情况下到达，那么这个邻居就是一个“强迫邻居”，而n本身就是一个跳点。
• 终点：目标点自然是跳点。

JPS的搜索过程不再是扩展当前节点的所有邻居，而是根据当前移动方向，利用跳跃规则直接寻找下一个跳点。这样，开启列表中的节点数量会急剧减少，可能只有A*的十分之一、百分之一甚至更少。在空旷、障碍物规整的地图上（如很多2D游戏、棋盘类游戏、RTS游戏），性能提升极其明显。

但是，JPS有它的局限性：

• 仅适用于均匀网格：它严重依赖网格的规整性。如果你的世界是导航网格（NavMesh）或者路点（Waypoint）图，JPS无法直接应用。
• 动态障碍物处理：JPS在预处理阶段（识别所有跳点）或实时跳跃时，都需要知道网格的通行状态。如果障碍物频繁变化（如可破坏的地形、动态开启的门），每次变化都可能需要更新跳点信息，带来额外开销。当然，也可以实时计算，但这会削弱其优势。
• 算法理解与实现复杂度：JPS的规则比A*复杂，正确实现需要仔细处理各种边界情况，比如对角线跳跃的优先级、死角的处理等。

2.3 HPA*（Hierarchical Pathfinding A*）：应对超大世界的“地图分层术”

当你的游戏世界非常大时，无论是A还是JPS，进行一次从世界一端到另一端的寻路，计算量都是难以接受的。HPA解决这个问题的思路是抽象与分层。

它的工作流程可以概括为：

1. 预处理 - 创建层次结构：将庞大的原始网格地图进行“分块”（Clustering），比如每10x10个格子作为一个“簇”（Cluster）或“区块”（Chunk）。然后，在每个区块的边界上，选取一些代表性的点作为“入口点”（Entrance/Exit Point）。接着，在区块内部，用A*或JPS预计算所有入口点两两之间的最短路径和代价。最后，将整个地图抽象为一个更高层的“抽象图”（Abstract Graph），图中的节点就是各个区块的入口点，边就是预计算好的内部路径代价。
2. 运行时 - 分层寻路：
   • 高层寻路：当需要从A点寻路到B点时，首先找到A、B所在区块的入口点，然后在抽象图上运行一次A*，找到一条从起点区块到终点区块、经过一系列入口点的“抽象路径”。这个搜索范围很小，因为抽象图的节点数（入口点总数）远小于原始网格的节点数。
   • 底层寻路：得到抽象路径后，再在相邻两个入口点所在的区块内部，进行精细的、小范围的寻路（可以用A*或JPS），将这些入口点连接起来，最终拼接成一条完整的、从A到B的具体路径。

HPA*的优势在于：

• 极大缩小搜索空间：大部分搜索是在很小的抽象图上完成的，速度极快。
• 路径质量接近最优：虽然由于抽象会损失一些精度，但通过合理的区块划分和入口点选择，最终路径与全局A*找到的路径代价非常接近。
• 非常适合超大、静态世界：开放世界、MMORPG大地图是HPA*的绝佳应用场景。预处理虽然耗时，但只需做一次（或在地图加载时做）。

HPA*的挑战：

• 预处理开销：构建抽象图和预计算内部路径需要时间和存储空间。地图越大、区块划分越细，预处理时间越长，存储的路径数据也越多。
• 动态更新成本：如果地图的通行状态发生变化（如桥断了），需要更新受影响区块的内部预计算数据以及抽象图，这比更新单一网格状态要复杂。
• 实现复杂度高：需要管理两层数据结构（原始网格和抽象图），并处理层间的路径拼接，代码结构比单一算法复杂。

2.4 算法选型决策表

如何为你的项目选择？可以参考下面的快速决策表：

一句话总结选型逻辑：小图或动态图用A；大而静的规整网格用JPS；巨大世界用HPA；追求开发效率的3D项目用NavMesh。**

3. 在Unity中实现JPS：实战与优化细节

理论说再多，不如一行代码。我们来看看如何在Unity中实现一个基础的JPS，并讨论一些关键的优化点。这里我们假设使用一个二维的bool数组grid来表示地图，true代表可行走，false代表障碍。

3.1 基础JPS实现框架

首先，我们需要定义节点类和核心的跳跃函数。

// JPS节点类，比A*节点多了父节点方向信息 public class JPSNode { public int x, y; public JPSNode parent; public float gCost, hCost, fCost; // 父节点指向此节点的方向向量 (dx, dy)，用于跳跃规则 public int parentDx, parentDy; public JPSNode(int x, int y) { this.x = x; this.y = y; } } // 核心：跳跃函数 // 从节点(startX, startY)沿着方向(dirX, dirY)跳跃，返回跳点或null private JPSNode Jump(int startX, int startY, int dirX, int dirY, int goalX, int goalY) { int curX = startX + dirX; int curY = startY + dirY; // 1. 检查是否越界或不可行走 if (!IsWalkable(curX, curY)) return null; // 2. 如果当前点就是目标点，它就是跳点 if (curX == goalX && curY == goalY) return new JPSNode(curX, curY); // 3. 检查“强迫邻居”（这是跳点的关键判定） if (HasForcedNeighbour(curX, curY, dirX, dirY)) { return new JPSNode(curX, curY); } // 4. 对角线方向跳跃的特殊处理 if (dirX != 0 && dirY != 0) // 对角线移动 { // 在对角线移动中，需要同时尝试水平和垂直方向是否能“跳”出跳点 if (Jump(curX, curY, dirX, 0, goalX, goalY) != null || Jump(curX, curY, 0, dirY, goalX, goalY) != null) { return new JPSNode(curX, curY); } } // 5. 递归地继续沿原方向跳跃 return Jump(curX, curY, dirX, dirY, goalX, goalY); } // 强迫邻居检查函数 (简化版，需根据八方向完善) private bool HasForcedNeighbour(int x, int y, int dirX, int dirY) { // 这里需要根据移动方向(dirX, dirY)和父节点方向，判断当前点(x,y)是否存在强迫邻居 // 规则是：如果从父节点到当前点的路径，为了到达某个邻居而必须“绕”过障碍物，则该邻居是强迫邻居。 // 具体实现需要处理水平、垂直、对角线共8种情况，代码较长，是JPS算法的核心逻辑之一。 // 例如，当向右水平移动(dirX=1, dirY=0)时，如果当前点(x,y)的上方(x, y+1)是障碍物， // 而右上角(x+1, y+1)是可走的，那么右上角这个点就是当前点的一个“强迫邻居”。 // 此时当前点(x,y)就是一个跳点。 // 实现时需要仔细处理所有方向组合。 return false; // 此处应为具体实现 }

主寻路循环与A*类似，但扩展邻居的方式不同：

public List<Vector2Int> FindPathJPS(Vector2Int start, Vector2Int goal) { // 初始化开放列表、关闭列表等... openSet.Add(new JPSNode(start.x, start.y) { gCost = 0, hCost = Heuristic(start, goal) }); while (openSet.Count > 0) { JPSNode currentNode = GetLowestFCostNode(openSet); // 从开放列表取f最小节点 if (currentNode.x == goal.x && currentNode.y == goal.y) { return RetracePath(currentNode); // 重构路径 } openSet.Remove(currentNode); closedSet.Add(currentNode); // **关键区别：获取后继跳点，而不是所有邻居** List<JPSNode> successors = GetSuccessors(currentNode, goal); foreach (JPSNode successor in successors) { if (closedSet.Contains(successor)) continue; float newGCost = currentNode.gCost + Heuristic(currentNode, successor); if (newGCost < successor.gCost || !openSet.Contains(successor)) { successor.gCost = newGCost; successor.hCost = Heuristic(successor, goal); successor.fCost = successor.gCost + successor.hCost; successor.parent = currentNode; // 记录父节点方向，用于后续跳跃判断 successor.parentDx = successor.x - currentNode.x; successor.parentDy = successor.y - currentNode.y; if (!openSet.Contains(successor)) openSet.Add(successor); } } } return null; // 未找到路径 } // 获取当前节点的所有后继跳点 private List<JPSNode> GetSuccessors(JPSNode node, Vector2Int goal) { List<JPSNode> successors = new List<JPSNode>(); // 获取当前节点的自然邻居方向（需要考虑父节点方向来剪枝） List<Vector2Int> directions = GetNaturalNeighbours(node); foreach (Vector2Int dir in directions) { JPSNode jumpPoint = Jump(node.x, node.y, dir.x, dir.y, goal.x, goal.y); if (jumpPoint != null) { successors.Add(jumpPoint); } } return successors; }

3.2 JPS实现中的关键优化与避坑指南

1. 方向剪枝（Pruning）：这是JPS性能提升的第一关键。在GetNaturalNeighbours函数中，不能简单地返回所有8个方向。必须根据父节点指向当前节点的方向，剔除掉那些不可能产生更短路径的冗余方向。例如，如果是从左边移动到当前点，那么再向左移动就是往回走，肯定不是最优路径的一部分，应该被剪掉。正确实现方向剪枝能大幅减少不必要的跳跃调用。

2. 强迫邻居规则的完整实现：HasForcedNeighbour函数的实现是JPS正确性的核心。网上很多简化版的JPS教程在这里都有错误或遗漏。你必须为8个移动方向分别编写准确的强迫邻居判断逻辑。一个常见的错误是忽略了对角线移动时，水平和垂直方向上的强迫邻居检查。建议画一个3x3的网格图，手动推导每个方向下的所有强迫邻居情况，并严格编码。

3. 启发函数的选择：在均匀网格中，切比雪夫距离（Chebyshev Distance）或对角线距离（Octile Distance）是八方向移动的最佳启发函数，它能保证找到最短路径且不会高估代价。曼哈顿距离（Manhattan）只适用于四方向移动。使用错误的启发函数会导致JPS找不到最优路径。

   // 八方向移动的启发函数（对角线代价为根号2≈1.4，这里用1和1.4近似） private float Heuristic(Vector2Int a, Vector2Int b) { int dx = Mathf.Abs(a.x - b.x); int dy = Mathf.Abs(a.y - b.y); // 假设水平/垂直移动代价为1，对角线移动代价为D2=1.414 float D = 1f; float D2 = 1.414f; return D * (dx + dy) + (D2 - 2 * D) * Mathf.Min(dx, dy); }

4. 跳跃函数的迭代实现：上述示例中的Jump函数是递归的，清晰但可能有栈溢出风险（对于极长的直线）。生产环境建议使用迭代（循环）方式实现跳跃函数，性能更好且更安全。

5. 数据结构优化：和优化A*一样，使用高效的优先队列（如二叉堆BinaryHeap）来管理开放列表，使用HashSet或基于网格坐标的快速查找结构（如二维数组Node[,]）来管理关闭列表和记录节点信息，能显著提升性能。

实操心得：在Unity中调试JPS时，一个非常有效的方法是将搜索过程可视化。在OnDrawGizmos函数中，绘制出所有被检查过的格子（用半透明颜色）、跳点（用醒目颜色）、最终路径（用线连接）。这能帮你直观地验证跳跃规则是否正确，强迫邻居是否被准确识别，以及路径是否最优。我曾经因为一个对角线方向强迫邻居的判断错误，导致在特定障碍物布局下寻路失败，可视化调试帮我快速定位了问题。

4. 在Unity中集成HPA*：分层思想落地

HPA*的实现比JPS更工程化，因为它包含预处理和运行时两大部分。我们以一个简单的2D网格地图为例，阐述核心步骤。

4.1 预处理阶段：构建抽象层

假设我们的地图是width * height的网格，我们决定将其划分为clusterSize x clusterSize（例如16x16）的区块。

public class HPAStar { private bool[,] walkableGrid; // 原始网格 private int clusterSize; // 区块大小 private Cluster[,] clusters; // 区块二维数组 private AbstractGraph abstractGraph; // 抽象图 public void Preprocess() { int clusterCountX = Mathf.CeilToInt((float)width / clusterSize); int clusterCountY = Mathf.CeilToInt((float)height / clusterSize); clusters = new Cluster[clusterCountX, clusterCountY]; // 1. 划分区块并识别入口点 for (int cx = 0; cx < clusterCountX; cx++) { for (int cy = 0; cy < clusterCountY; cy++) { Cluster cluster = new Cluster(cx, cy); // 找出该区块四条边上的所有可行走格子，作为候选入口点 // 通常会对入口点进行筛选，比如间隔选取，或只保留拐角点，以减少数量。 cluster.entrances = FindEntrancesOnBorder(cx, cy, clusterSize); clusters[cx, cy] = cluster; } } // 2. 构建抽象图节点（即所有入口点） abstractGraph.nodes = GetAllEntrancesFromClusters(); // 3. 预计算区块内部路径代价（核心） foreach (Cluster cluster in clusters) { // 对于该cluster内部的每一对入口点(A, B) foreach (var entranceA in cluster.entrances) { foreach (var entranceB in cluster.entrances) { if (entranceA == entranceB) continue; // 在cluster内部的局部网格上，运行一次A*或JPS，计算从A到B的最短路径代价 float cost = ComputeIntraClusterCost(cluster, entranceA, entranceB); // 将结果(entranceA, entranceB, cost)存储起来，作为抽象图的一条边 abstractGraph.AddEdge(entranceA.id, entranceB.id, cost); } } } // 4. （可选）连接相邻区块的入口点 // 对于相邻的两个区块，将它们边界上相邻的入口点连接起来，代价就是穿过边界的移动代价（通常很小，如1）。 ConnectInterClusterEdges(); } // 在区块内部进行小范围寻路 private float ComputeIntraClusterCost(Cluster cluster, Entrance a, Entrance b) { // 获取该cluster对应的原始网格区域 // 使用一个更高效的、针对小范围优化的A*或直接使用JPS进行计算 // 返回路径代价，如果不可达则返回无穷大(Infinity) // **优化点**：这个计算可能很耗时，但它是预处理，只做一次。可以考虑使用更快的算法如Dijkstra计算所有点对，或者只计算部分关键点对。 return RunLocalSearch(cluster.localGrid, a.localPos, b.localPos); } }

4.2 运行时寻路阶段

public List<Vector2Int> FindPathHPAStar(Vector2Int startWorld, Vector2Int goalWorld) { // 1. 将世界坐标转换为簇坐标和局部坐标 Cluster startCluster = GetClusterFromWorldPos(startWorld); Cluster goalCluster = GetClusterFromWorldPos(goalWorld); Entrance startEntrance = FindNearestEntrance(startCluster, startWorld); Entrance goalEntrance = FindNearestEntrance(goalCluster, goalWorld); // 2. 高层寻路：在抽象图上寻找入口点序列 List<Entrance> abstractPath = FindAbstractPath(startEntrance, goalEntrance); if (abstractPath == null) return null; // 抽象层不可达 // 3. 底层寻路：拼接具体路径 List<Vector2Int> fullPath = new List<Vector2Int>(); Vector2Int currentStart = startWorld; // 首先，从起点走到抽象路径的第一个入口点（在起点簇内部） List<Vector2Int> pathToFirstEntrance = FindIntraClusterPath(startCluster, currentStart, abstractPath[0].worldPos); if (pathToFirstEntrance == null) return null; fullPath.AddRange(pathToFirstEntrance); currentStart = abstractPath[0].worldPos; // 然后，遍历抽象路径，连接每一对相邻的入口点 for (int i = 0; i < abstractPath.Count - 1; i++) { Entrance from = abstractPath[i]; Entrance to = abstractPath[i + 1]; // 如果两个入口点在同一个簇内，使用预计算的内部路径（或实时计算） if (from.clusterId == to.clusterId) { // 可以直接使用预处理时存储的路径点序列，或者根据存储的代价和入口点信息快速重建路径。 List<Vector2Int> intraPath = GetPrecomputedIntraClusterPath(from, to); fullPath.AddRange(intraPath); } else { // 它们位于相邻簇，路径就是穿过边界的一条短边，通常就是两个入口点本身。 fullPath.Add(to.worldPos); } currentStart = to.worldPos; } // 最后，从抽象路径的最后一个入口点走到终点（在终点簇内部） List<Vector2Int> pathFromLastToGoal = FindIntraClusterPath(goalCluster, currentStart, goalWorld); if (pathFromLastToGoal == null) return null; fullPath.AddRange(pathFromLastToGoal); // 4. （可选）路径后处理：平滑（Smoothing） // 由于路径是由一段段拼接而成，可能在连接处有“拐角”。可以运行一个简单的线段简化算法（如拉直测试）来平滑路径。 return SmoothPath(fullPath); }

4.3 HPA*实战要点与权衡

1. 区块大小（Cluster Size）的选择：这是最重要的参数。区块越小，抽象图越大，高层寻路可能变慢，但底层寻路更快、路径更精确。区块越大，则相反。需要根据你的地图大小和典型寻路距离进行测试。一个经验法则是，让区块大小略大于游戏中单位的典型“视野范围”或“一次决策的移动距离”。

2. 入口点（Entrance）的选择策略：最简单的策略是选取区块每条边上的所有可行走格子。但这会产生大量入口点，导致抽象图庞大，预处理和存储开销大。优化策略包括：只选取边的中点；只选取可行走区域的拐角点；或者使用更复杂的算法（如“门户点”）来减少入口点数量。

3. 预计算数据的存储与加载：预处理的结果（抽象图、内部路径代价）可以序列化（如保存为ScriptableObject或二进制文件），在游戏加载时读取，避免每次运行都计算。注意数据量，对于超大地图，可能需要按需加载（流式处理）。

4. 动态障碍物处理：这是HPA的难点。如果障碍物变化只影响少数几个格子，一个简单（但粗糙）的方法是：标记这些格子所在的区块为“脏”（Dirty）。当寻路请求涉及到“脏”区块时，不使用预计算的内部路径，而是实时在该区块内进行一次局部A寻路。这会导致该次寻路变慢，但避免了全局预处理。更精细的方法需要更新受影响区块的入口点连通性和内部路径代价，并可能波及抽象图，实现复杂。

5. 路径拼接与平滑：HPA*生成的路径是由多个“线段”拼接而成，在入口点处可能会有不自然的直角转弯。可以在得到完整路径后，运行一个路径拉直（Path Straightening）或光线投射（Raycasting）的后处理步骤：从起点开始，尝试向路径后方的点“画”一条直线，如果直线可达（无碰撞），就跳过中间的点。这能使路径看起来更自然，类似于NavMesh生成的平滑路径。

注意事项：HPA*的预处理时间可能很长，特别是当区块划分很细、入口点很多时。务必在编辑器模式下进行预处理，并将结果保存为资源。不要试图在游戏运行时或加载时进行全量预处理。对于程序化生成的地图，可以考虑在后台线程进行预处理，或者使用更轻量级的动态分层方法。

5. 性能对比实测与常见问题排查

纸上得来终觉浅，我们最终还是要看实际数据。我在一个512x512的均匀网格地图上（30%随机障碍物），使用Unity Profiler进行了简单的性能测试（在同一台PC上），测试内容是进行1000次随机起点-终点的寻路请求（保证路径存在）。结果对比如下：

测试结论：

• JPS在均匀网格上的性能优势是碾压性的，平均耗时仅为优化A*的8%左右。
• HPA在短距离寻路时，因为大部分情况下只需要在一两个簇内搜索，速度甚至比JPS还快。对于跨越整个地图的超长距离寻路，其耗时也远低于直接使用A或JPS进行全局搜索，体现了其“分层”的价值。
• 基础A*在无任何优化的情况下，性能确实难以满足高频需求。

5.1 常见问题与排查技巧

在实际集成这些算法时，你肯定会遇到各种问题。下面是一些常见坑点和排查思路：

问题1：JPS寻路失败，找不到明明存在的路径。

• 排查：99%的问题出在HasForcedNeighbour函数或方向剪枝逻辑。
• 技巧：实现一个可视化调试工具。将每次Jump函数尝试的坐标、最终找到的跳点、开放列表和关闭列表的节点都用不同颜色在Scene视图绘制出来。观察搜索过程在哪里中断，强迫邻居是否被正确识别。对比一个已知的、A*能成功寻路的地图配置。

问题2：JPS寻到的路径不是最短路径，看起来有点“绕”。

• 排查：首先检查启发函数是否适用于你的移动方式（八方向用切比雪夫/对角线距离）。其次，检查移动代价计算是否正确，特别是对角线移动的代价是否是sqrt(2)的合理近似。最后，检查跳跃规则中，对角线跳跃时对水平和垂直方向的递归调用逻辑是否正确，遗漏会导致错过关键跳点。

问题3：HPA*的路径在区块边界处有奇怪的折返或卡住。

• 排查：检查入口点的连通性。确保两个相邻区块在边界上的入口点是“对齐”且可相互直达的。一个常见错误是入口点选择在墙角，导致从相邻区块的入口点无法直线到达。确保在ConnectInterClusterEdges阶段，正确连接了相邻且可视的入口点。
• 排查：检查路径拼接逻辑。在从“当前点”走到“下一个入口点”的底层寻路时，确保“当前点”的坐标是正确的（是上一个路径段的终点，而不是起点）。路径拼接的索引错误会导致断点。

问题4：集成后整体性能提升不明显，甚至更慢了。

• 对于JPS：检查你的地图是否真的是均匀网格。如果你的游戏使用的是NavMesh（多边形）或Waypoint（点图），JPS无效。检查障碍物是否非常密集且不规则，在极端复杂的地形中，JPS的跳跃优势可能被削弱，因为到处都是强迫邻居，导致跳点很多。
• 对于HPA*：检查区块大小是否太小。如果区块太小，抽象图会非常大，高层寻路的开销可能抵消了分层带来的好处。尝试增大区块大小。检查预处理数据是否被有效缓存和复用，避免每次寻路都重新计算抽象路径。

问题5：动态障碍物导致路径失效。

• 对于JPS：实现一个动态障碍物管理器。当障碍物状态改变时，标记受影响网格区域内的所有跳点需要重新验证。可以在下一次寻路经过该区域时进行惰性更新（重新计算跳跃），或者主动更新一个局部区域的跳点缓存。对于频繁变化的场景，JPS的优势会打折扣，需要评估是否仍适用。
• 对于HPA*：采用**“脏区块”策略**。将障碍物变化影响到的区块标记为脏。寻路时，如果路径涉及脏区块，则对该区块内的路径段进行实时局部寻路（使用A*或JPS），而不是使用预计算的数据。同时，可以设置一个后台线程，在空闲时慢慢清理（重新预计算）“脏区块”。

问题6：移动端（Android/iOS）上性能不佳。

• 优化：避免在每帧进行多次寻路。使用队列或协程将寻路请求分散到多帧完成。对于大量单位（如RTS小兵），可以考虑群体寻路（Flock Pathfinding）或流场（Flow Field）算法，它们比为每个单位单独运行JPS/HPA*更高效。
• 优化：简化数据结构。使用struct代替class来表示节点，减少GC（垃圾回收）压力。使用对象池重用节点对象。将网格数据用一维数组bool[]或BitArray存储，访问比二维数组bool[,]更快。
• 优化：降低更新频率。不是每个单位每帧都需要寻路。对于AI，可以降低寻路的目标更新频率（例如每秒1-2次），在两次寻路之间使用转向行为（Steering）进行局部避障。

最后，我想分享一个深刻的体会：没有银弹。JPS和HPA是强大的工具，但它们是为特定问题域设计的。在决定使用它们之前，先用Profiler工具精准定位你的性能瓶颈是否真的在寻路上。有时，优化网格大小、减少同时寻路的单位数量、使用更简单的AI行为，可能比更换一个复杂的寻路算法带来更直接的收益。但当你确实需要处理大规模、高性能的寻路需求时，熟练掌握JPS和HPA，无疑会让你在Unity游戏开发的性能优化战场上，拥有更强大、更专业的武器库。