有给别人用过的，确实好用。哪怕你缓存起来，也占用不了多少，一个节点的引用一般占用4个字节来计算，存1000个也就4kb，并且有些界面关闭和销毁会回收掉，而且还能扩展一些规则，如名字下划线开头的节点，就不会存入uiMap之类的，进而降低内存占用。
还有就是没太理解你说的保存key是啥，我这上述实现中，假设预制1挂了组件1，预制下有node1，那么组件脚本中，会有ui = { “node1”: node1的节点引用 }，从而达到在组件中通过this.ui[“node1”]直接获取到预制上的node1节点。
虽说预制改节点名字有丢失风险，但对比find的是可接受的。对比@property，这玩意有可能忘记挂，或者多人协作时，导致预制冲突，对比这些后果，这样因改名丢失其实是可以接受的，并且习惯后，后面改节点名的频率其实也不高
按上文中说的，{“节点名”：节点}，节点名就是key，节点就是value，键值对，在外部的时候就是 this.ui[节点名]，组件内部拦截ui的get，然后用key去this.ui检查有没有这个节点名，有就用cocos的方法查找返回给外部，我大概描述的东西
1赞
假设通过uiMap来获取，只需要创建时遍历一次所有节点，之后无论获取哪个节点，时间复杂度都为1，一步到位。而通过find，假设find的路径为xx1/xx2/xx3,假设要查找的节点刚好都在children数组的末尾，假设xx1的children的数组长度是L，xx2的children数组长度为M，那么find一次xx3的最大时间复杂度时L x M
嗯你的意思还是提倡缓存，其实这点我没反对，我只是提出了我的小建议，项目场景不同考虑的也不同，没啥大问题，对于外部来说都一样的。
不一样；在脚本里拖属性的话，prefab里记录了，变量名关联的节点ID了。同样是实例化一个prefab，拖节点在实例化那里就可以直接给变量赋值了。 纯代码就多一步遍历节点树
也不是提倡缓存，只是说为啥我会用缓存 
，然后缓存在map和find的一些优缺点，都说一下，当然也期待有更多的优化方案
根据uuid取节点，可以不用遍历就一步到位么？
好方法。。
getChildByUuid()一样要遍历 
那@property的方法效率也没高啊，引擎加载预制体的时候，一样是通过遍历去取节点的
cc.instantiate(cc.prefab)的时候，无论你拖属性还是不拖属性，内部都要遍历。你拖属性的时候，在内部操作的时候就直接赋值了；不拖属性cc.instantiate()完了后，你还要在代码cc.find / getchildbyname()等来遍历找节点
不是的，@property节点或组件，在预制体中的表现是关联了其id（数组下标，预制体本身是个数组，打包后结构不一样，但原理差不多），所以它是同步的，不需要遍历。你要是遍历那属性一多的话那可爆炸了，不可能这么设计的。
你编辑器里拖上去，只是编辑器里查找到了。每次保存代码回到编辑器，或者编译运行，又会重复这个查找的过程。
所以拖上去并不能减少运行前的查找效率
这个id对应的数组叫啥？有这数组还需要什么map，代码里直接访问这个数组取node就好了
不是啊，我是说预制体（场景）文件本身是采用数组结构去记录节点跟组件，解析过程才将数组转换成节点的树状结构。
哦，那这样确实效率会提高的