std::priority_queue不支持decrease-key操作，导致A*无法更新已入队节点的f值，从而可能找不到最优路径；应改用std::set或带惰性删除的堆实现。
为什么直接用 std::priority_queue 会卡在“找不到更优路径”？
因为 std::priority_queue 不支持修改已入队节点的优先级（即无法做 decrease-key 操作），而 A* 在重估某个已访问节点的 f(n) = g(n) + h(n) 时，必须能更新它在开放列表中的位置。硬塞重复节点会导致内存和时间浪费，还可能错过最优解。
实操建议：
- 改用
std::set<:pair node>></:pair>或std::set自定义比较器（按f值升序），插入/删除/查找都是O(log n)，且可 erase 后重新 insert 实现“更新” - 或者用
std::vector+std::make_heap手动维护，配合一个std::unordered_map<node float></node>记录当前最小f值，每次 pop 前检查是否过期（lazy deletion） - 别用
std::priority_queue<Node>直接存结构体——除非你重载了operator<且确保每次 push 的都是最新状态
曼哈顿距离 vs 欧氏距离：选哪个影响路径平滑性？
网格地图（上下左右移动）用曼哈顿距离：abs(x1 - x2) + abs(y1 - y2)；允许斜向移动（8方向）时，用对角线距离更准：max(abs(x1 - x2), abs(y1 - y2))。欧氏距离虽然数学上更“真实”，但在整数网格中会导致浮点误差、比较不稳定，且不满足 A* 要求的“启发函数不能高估”的条件（除非你严格保证浮点精度）。
常见错误现象：路径绕远、反复横跳、甚至死循环（尤其当 h(n) 偶尔大于实际代价时）。
立即学习“C++免费学习笔记（深入）”；
使用场景判断：
- 纯四向移动 → 用曼哈顿
- 八向移动 + 允许斜向成本为 1.4 → 用对角线距离（
dx + dy - min(dx, dy)），或预计算查表避免重复开方 - 任意角度移动（如 navmesh）→ 改用欧氏，但必须用
double且所有比较加 epsilon 容差
Node 结构里哪些字段不能省？
最少要存这四个：x, y, g, parent。漏掉 parent 就没法回溯路径；只存 f 不存 g 会导致无法正确更新邻居的 g 值（因为 g_new = g_current + cost）；没 x/y 就没法算 h，也没法查是否在关闭列表里。
性能提示：
- 用
std::unordered_set存关闭列表，key 推荐用y * width + x（整数哈希比 pair 快） - 开放列表若用
std::set，比较函数里别实时算h——提前算好存在Node里，否则每次比较都触发一次计算 - 不要把整个地图数据存在每个
Node里，传引用或全局单例访问障碍信息
遇到“路径不存在”却没报错，怎么快速定位？
最常被忽略的是起点或终点本身是障碍物——A* 默认不检查，直接从起点扩展，结果第一个邻居就全被跳过，开放列表变空后静默返回空路径。
调试建议：
- 初始化时立刻检查
grid[start.y][start.x]和grid[end.y][end.x]是否可通行，不通过直接 return - 每次从开放列表 pop 节点后，打一行日志：
pop (x,y), g=..., f=...，如果第一行就是终点，说明启发函数爆炸了；如果 pop 几十轮后列表为空，大概率是地图连通性问题 - 把关闭列表 size 输出出来，正常寻路中它应持续增长；如果卡在 1 或 2 不动，说明邻居遍历逻辑有 bug（比如坐标越界没判，或方向数组写错）
真正难调的不是公式，是边界和状态同步——比如更新邻居时用了旧的 g 值，或忘记把新节点加入开放列表就去设 parent。
