看了你说的这个“寻路深度越少就越好吗？”，我就被雷到了。
寻路深度少说明做的运算量少，不就证明“时间复杂度小”吗？怎么就不好了。
1赞
翻CC+1。虽然我也觉得这种标题党，但是要比就必须翻。
那要严格一点要求不允许把go遍译成 Webassembly来测试 
你要不把你那个demo， 移除掉寻路算法， 只留接口打个zip项目包， 要ta实现寻路算法内容就行， 因为人家时间很宝贵麻
哥们，A星寻路我很多年前就开始写了，完全独立写的。我不确定你的是不是自己独立写的。
这个是我写的A星寻路，可以按角色半径大小寻路，就问你你的寻路能实现这样的功能吗？这个在商用方面才是最多的，但是却很少人能提供。
A星寻路算法如何按角色面积大小进行寻路的实现方案，代码TypeScript版 - Creator 3.x - Cocos中文社区
测试案例：
https://easymapeditor-1258223435.cos.ap-guangzhou.myqcloud.com/astarfk/demo1/web-mobile/index.html
你连最基本的暴力测，随机测，平均测都没完整过一遍，你就觉得RCA最快，还拿遍历格子说事，扯时间空间，大学生机器学习都有热力图，你就拿单个例子来证全部
其实两个人鸡同鸭讲。真是佩服楼主，还有耐心回复了一天，要我早就开喷了。
1赞
代码我都提供给你了，你不测是你的事，不要像审犯人一样问我。反而我让你提供一下你的源码和demo你啥都提供不了。
昨天给你的地图本，你测的路线我用A星测试，基本就几百左右是寻路深度，不知道你喊什么服了没？
用我js版的寻路消耗也就1-3毫秒。地形很多复杂的路径你也没测。而且我问你的寻路深度是多少你也答不上来，问你寻路检测了多少个格子也答不上来，就全在凭感觉感受效率。
我只是想知道你的A星寻路好，到底好在哪里，在哪里做了优化，时间复杂度是多少，空间复杂度是多少，你不但答不上来，还大言不惭的说，就算遍历几千上万遍只要感知不到时间就行，你对数据结构设计一点了解都没有。
下面截图是昨天你用你的算法测的，所谓服了吗的路径，用js测就几百的A星寻路深度，消耗不过2-3毫秒，把你兴奋得跳起来。
我脾气算好了，其实我早就想做你说的那种了，跟他聊技术的东西他总是有意去回避不利的。然后单方面像审犯人那样要求我单方面举证，我耐着脾气给他证据，他还不服，还有其它证据。就是要胡搅蛮缠到底，把他装得很高大上的样子，老子从事游戏开放13年，大多数游戏技术都经历过，他这种人我还真没放在眼里。
要是我直接拉黑啦，懒得讲那么多，，
没必要再和他battle下去了，图啥呢？该说的说了，该做的都做了。
我在贴子开始的地方添加了测试demo了，你测试看看找不找得到最佳路径
我做了一个简单的基准测试：
Go 源码来自：https://github.com/3264876581/goAstar/tree/main
TS 源码来自：楼主编辑器内点击下载基础框架
地图数据来自：Go 项目中的 mapObstacle_500.json
目标点来自：Go 项目中的 0,0 -> 499,499
由于没有翻译源码到 Go/TS 来减少变量，为了我认为的 “公平” 起见，做了以下调整：
- 由于 JS 有 JIT 机制，所以我对两者都编写了预热代码，并取最大、最小、平均耗时。由于 Go 有 AOT 机制，所以我启用所有优化 flag 对其进行了编译再运行。
- 关闭了所有日志打印。
- 调整了结果打印的格式，好进行对比。
同机器得出结果：
TS:
bun index.ts
=== load map_500.json & build road nodes ===
build map time (ms): 56.498
baking time (us): 7369171.500
baking time (ms): 7369.183
check FinalPathList:
0 -> x: 0 y: 0 nodeType: 0
1 -> x: 27 y: 138 nodeType: 0
2 -> x: 483 y: 366 nodeType: 0
3 -> x: 485 y: 369 nodeType: 0
4 -> x: 486 y: 372 nodeType: 0
5 -> x: 499 y: 499 nodeType: 0
check SmoothFinalIndex:
index 0
index 1
index 2
index 3
index 4
index 5
x:
x: 0 y: 0
x: 27 y: 138
x: 483 y: 366
x: 485 y: 369
x: 486 y: 372
x: 499 y: 499
--- pair #0 stats ---
seekPath min (us): 182.791
seekPath max (us): 519.166
seekPath avg (us): 222.035
seekPath min (ms): 0.183
seekPath max (ms): 0.520
seekPath avg (ms): 0.222
Go:
go build -trimpath -ldflags='-s -w' -o main_fast ./Main && ./main_fast
NewMapManager Start Time: 1763470221159
NewMapManager End Time: 1763470221165
NewMapManager Time Taken: 6 milliseconds
=== Go PathFind benchmark on mapObstacle_500.json ===
check FinalPathList:
0 -> x: 0 y: 0 nodeType: 0
1 -> x: 28 y: 65 nodeType: 0
2 -> x: 424 y: 455 nodeType: 0
3 -> x: 428 y: 465 nodeType: 0
4 -> x: 434 y: 471 nodeType: 0
5 -> x: 499 y: 499 nodeType: 0
check SmoothFinalIndex:
index 0
index 1
index 2
index 3
index 4
index 5
x:
x: 0 y: 0
x: 28 y: 65
x: 424 y: 455
x: 428 y: 465
x: 434 y: 471
x: 499 y: 499
--- Go PathFind stats ---
min (us): 2972.000
max (us): 3492.000
avg (us): 3149.000
min (ms): 2.000
max (ms): 3.000
avg (ms): 3.000
最终总结（AI）：
注意：Go 的日志中毫秒 (ms) 数值似乎有取整现象，因此下表统一使用微秒 (us) 数据换算为精确的毫秒 (ms) 进行对比。
| 性能指标 (Metric) | TS (Bun) | Go | 备注 |
|---|---|---|---|
| 地图构建/初始化耗时 (Map Build/Init) | 56.498 ms | 6 ms | Go 的初始化速度显著快于 TS |
| 预处理耗时 (Baking Time) | 7369.183 ms | - | TS 有明显的 Baking 阶段，Go 日志未体现 |
| 寻路平均耗时 (PathFind Avg) | 0.222 ms | 3.149 ms | TS 寻路速度约是 Go 的 14 倍 |
| 寻路最小耗时 (PathFind Min) | 0.183 ms | 2.972 ms | - |
| 寻路最大耗时 (PathFind Max) | 0.520 ms | 3.492 ms | - |
简要分析：
- 寻路性能：在该测试场景下，TS 的寻路算法运行速度极快，远远优于 Go 的实现。
- 启动与预处理：TS 版本虽然寻路快，但有一个非常耗时的 7.3秒 “Baking” (烘焙) 过程，以及较慢的地图构建 (56ms)。相比之下，Go 版本启动极快 (6ms)，似乎没有昂贵的预处理步骤。
-
路径差异：两者生成的路径节点 (
FinalPathList) 并不完全一致（中间节点坐标不同），这说明两者使用的寻路算法逻辑、启发式函数或地图数据结构可能存在差异。
有些源码改动是 AI 所写，源码地址：https://pan.baidu.com/s/1XN6RTdYpwLe70mWgZunkUw?pwd=r3vm
不保证这个基准测试结果完全正确，大家可纠正其中可能的错误再继续尝试。
7赞
笑死了，你以为我找不到你的破绽了，说的天衣无缝
你自己好好对比下，贪心不足蛇吞象，把自己的路线吞的这么远，所谓的少步数只是对路线的妥协，你这跟A有关系吗。这么小的地图偏差这么多
还有，你自己的例子连F都算不明白就说自己早写了A星，足以见是多么自大
我真的想笑，还说遍历格子越少越好，我早就说了，寻路是时间和路线的权衡，到你这里就变成格子少的最牛逼哈哈
这只是破绽其中之一，我还没仔细找你更多的破绽，就你这什么外墙角，我后处理早就试过了，应付下简单地图骗骗自己
太有意思了，边吃瓜边学习
你以为你用什么外墙角提前存一下，看似能驱动寻路马上跳过，你知不知道在百万格地图，你的外墙角映射关系，比蜘蛛网的打的结还要多，用一个巨量的内存换理论上的性能提升，结果寻出来偏到十万八千里了
越想越搞笑，我随便动一块地图，你的蜘蛛网又要重新映射计算下哈哈。
1赞
别说商用了，高德地图准确度都比你的强