astar类需用坐标pair作状态、priority_queue配greater实现小顶堆、unordered_set存y*width+x哈希去重；避免递归和预建节点，超限返回失败而非死循环，小网格手trace验证流程。
怎么写一个能跑通的 AStar 类，不卡死也不绕路
核心是状态表示 + 优先队列 + 闭集合去重。别用递归实现主循环，容易栈溢出；也别把所有格子预生成节点对象——内存暴涨还缓存不友好。用坐标 std::pair<int int></int> 当状态最轻量，std::priority_queue 配自定义比较器，闭集合用 std::unordered_set 存哈希值（比如 y * width + x）。
常见错误现象：std::priority_queue 默认是大顶堆，得传 std::greater 或重载 operator；闭集合漏加“已扩展节点”，会导致反复回溯；启发式函数返回负数，优先队列顺序全乱。
- 启发式必须满足：0 ≤ h(n) ≤ 实际最短距离（否则不保证最优）
- 地图边界检查必须在邻居生成后立刻做，别等进队列再判——避免无效入队
- 如果地图动态变化，每次调用前清空闭集合和开集合，别复用旧状态
heuristic 选曼哈顿还是欧氏距离，差别在哪
游戏网格地图基本都用曼哈顿距离（abs(x1-x2) + abs(y1-y2)），因为移动限制在四方向或八方向，欧氏距离会高估斜向成本，破坏可采纳性（admissibility），导致路径非最优。只有你允许任意角度移动且代价按直线算，才考虑欧氏。
八方向地图（斜移代价为 1.414）可用对角线启发式：min(dx, dy) * 1.414 + abs(dx - dy)，比纯曼哈顿更紧，搜索更快。
立即学习“C++免费学习笔记（深入）”；
- 用错启发式最直接的表现：A* 返回的路径比 BFS 找到的还长
- 如果地图有不同地形代价（如泥地耗 3 点，草地耗 1 点），启发式仍按最低单位代价估算，不能乘地形系数
- 浮点启发式要小心精度问题，
std::priority_queue对float比较不稳定，建议转成int放大 100 倍
怎么让 AStar::search() 支持中断和复用
别写成一次性返回完整路径的函数。实际游戏里玩家移动中障碍可能突变，或者帧率受限需分帧计算。把状态拆成成员变量：std::priority_queue<node> openSet</node>、std::unordered_map<key node> cameFrom</key>、std::unordered_set<key> closedSet</key>，暴露 step() 方法，每次只处理一个节点。
这样既能插帧执行，也能在找到目标前随时 reset()，还能复用已算过的部分状态（比如从同一起点多次搜不同终点）。
- 中断时记得保存当前
openSet顶部节点的估价，下次从它继续，别清空重来 -
cameFrom用std::unordered_map而不是std::vector<:vector></:vector>，稀疏地图下内存省一个数量级 - 不要在
step()里返回路径——路径要靠外部调用reconstructPath()回溯生成，避免重复遍历
为什么用 std::priority_queue 却改不了队列里的节点优先级
因为 std::priority_queue 不支持降键（decrease-key）操作。这是 A* 实现里最容易被忽略的性能坑：当发现更优路径到达某节点时，你不能更新它在队列里的优先级，只能插入新节点，靠闭集合后续过滤旧节点。
结果就是队列膨胀，尤其在低启发式或高障碍密度地图里，openSet 尺寸可能比总格子数还大几倍。
- 这不是 bug，是标准容器限制，接受它比换
boost::heap更实际 - 真正影响性能的是闭集合查找速度——务必用
std::unordered_set，别用std::set - 如果真卡在队列大小，可以加个硬限制：当
openSet.size() > 10000时直接返回失败，比死循环强
路径规划没玄学，但每个判断分支都得对齐你的地图模型和移动规则。写完先用 5×5 网格手 trace 一遍节点进出队列顺序，比跑十次 demo 更早发现问题。
