你举例的时候，说的就是编译后多了 2 层的调用导致的开销来证明 async await 的问题，怎么不是在说调用嵌套越多性能开销越大，那我按你的逻辑，不就是 M 层调用，M 越大性能越差？
我说了半天，是在和你说，你要真注重性能，写汇编就行了，用什么 js 呢？
然后我说的核心点你没理解而已，你关注于 20% 鸡毛蒜皮的点，而没办法证明 async await 的问题。
我们当然是在争论。但是争论得有理有据。你没抓住性能的核心问题，纠结于鸡毛蒜皮的地方，这才是最大的问题。
我们纠结的点在于如何兼顾游戏性能和优雅的编码。
有开发要在技能和动作这种肯定要处理中断的业务中抱怨 async 和 await 不支持中断，而且性能差，我当然不同意这种说法。
这种在确定技术方案的时候当然要考虑调用频率，中断业务，更要兼顾游戏性能的地方，简单的把锅甩给 async/await ，反驳肯定是要反驳的。
我也在反驳啊 
，因为他说无法中断，其实callback本身也无法中断，async/await要处理的，callback也是要处理的，只是用async/await很容易忽略的一点是在await后，如果在ui组件里，还得考虑ui被销毁，这点容易被忽略，实际上callback也是要处理这个问题。
我这么说吧，你 async/await 用完后出问题，这个开发用回调函数也一样出问题。他只是没用回调的方式而已，这不是是 async await 的锅。
你用生成器解决 UI 有生命周期而导致的问题。是一个解决方案，但二者特性不一样，不能比较的。
你说的没错，是这样的
Ui逻辑随便用，gameplay特别是能update解决的，慎重，主要因为不好停止
1赞
赞同你的评价。异步会遇到的问题，回调也一定会遇到，相比之下异步更方便
只是编译后的代码体量可能在不同平台不一致
我个人感觉吧，首先promise的出现就是不想代码里出现地狱式回调，还有增强代码的可读性。因为我们在阅读的时候都是从上而下，promise阅读起来就很爽啊，而且他产生的额外内存还不至于导致性能大幅度降低吧。（抛开量来谈都是耍流氓不是）。而且真正导致性能的问题还不是渲染和大量复杂的计算么。promise真的太冤了。
其二吧。。虽然说promise不能终止。。但是我可以封装起来，主动从外部去主动让他主动走catch也算是终止吧。根据参数来决定catch里执行什么逻辑也算是一种变向终止吧。
你的回复好像诗啊
我管它生成的代码和性能咋样，用得爽就行，，
如果项目中有大量async，那本身就是写法的问题吧，要做好封装吆
项目中不要直接用async，可以参考cocos tween的做法，封装一个带Node参数的async。
深有感触，一定要足够理解这个语法才适合用
为啥呀，如果有了具体会导致什么样的后果呢
好的，谢谢，不过为什么项目中不要直接用async呢
官方的tween的callback，也算有点问题，没有随着node的生命周期取消
例如请求网络数据回来慢，但展示信息的label已经销毁，如果不封装异步，这时候调用label.string = str;游戏就报错。
加载资源同理。
当然你也可以加判断提前终止，但这是牛马该干的事情吗？判断加多了代码臃肿，偶尔忘了还得背锅 。
这个封装留给项目主程干吧！
如果用的是383，不建议直接使用 promise 那一套，之前原生平台测试有问题，详见 【383】await async 原生平台与网页、微信小游戏效果不一致
不确定其他版本是否有类似问题，也没有找到问题的根源，我的解决方案是用的自己封装的异步回调对象替代。
这就是个解决callback回调地狱的语法糖而已。。。 编译后都是一样的，当然可以用。 至于异常处理，那是实现的业务逻辑是否严密， 和promise async await没有任何关系
3赞
可能平常AI对话用多了 