个人觉得这种问题，按道理，应该有一个3.7.4活着3.7.3-xxx 修复版才行，总不能要求每一个使用者都去合并 pr，而且也要考虑并不是所有人都知道如何操作。还有就是新用3.7.3的人，就直接蜗牛般的启动时长，人家就以为，这引擎，就这样，卡得要死。
如果不出3.7.4的话，我觉得官方对引擎的品控是真的有待提高，我觉得仅仅是这个问题，对使用者的影响是很大的，经常需要预览启动，浪费着每一个使用者的时间和耐心，官方却不计划出个小版本修复这个问题。
@jare
官方几个编辑器大佬搞比赛去了， 那不得还是要解决了质量品控问题么？基础的东西没做好，锦上添花的意义又有多大。提升外在固然也是提升，但是 cocos 这个内在，真的得好好提升一下才行了。
cocos 要思考如何打破现在这个循环：遇到 bug->升级版本->遇到新bug->升级版本->…
这次回归用 cocos 从3.5一路到3.7，我的有几点明显感受：
1.每一个版本，都不稳定，尤其是3.5根本没有达到做产品的品质。
2.每一个版本都解决上一个版本的问题，但是又引入新的问题，而很多问题，其实就是品控不严，测试不全导致的。比如3.5的音效内存泄露，3.6的 spine 闪退、3.6的图集精灵名字丢失，3.7的变更了第三方包的识别方式（目前没看到任何地方提到过），3.7的编辑器蜗牛预览等等。这些明显的问题，反应出来的是引擎品控环节的问题。
3.一些常用的组件，还存在着匪夷所思的 BUG 或者不合理的逻辑设计。比如：active=false 的精灵会打断合批；复用 spine 的 Skeleton，通过替换 data 的方式替换显示的内容，会导致各种怪异的错误，如果不报错，每一次替换 data，内存就会泄露一部分，除非Skeleton销毁；2d 的合批实现代码，关键逻辑之前提过，似乎少了索引长度的判断，导致某些情况下，渲染直接抛出越界错误，导致渲染中断；音效的 AudioSource 组件无法重复使用（切换音乐的时候，经常会出现，原来的音乐根本没停，2个音乐在播放，现在版本不确定是否还有问题）等等
4.对已释放的资源处理相当不友好，如果某个资源被释放了，但是还存在渲染组件用到，引擎就是单纯的各种空指针，如果我们想知道什么资源的问题，还得去自己打断点，设置条件，然后看上下文一个个去找，去猜。所以，引擎是出于什么原因（别说是效率，一个 if 分支而已，比起一些不合理的逻辑轻量多了），不能加一个资源已释放的 if 判断，并且输出资源 id，节省下使用者的时间呢？诸如此类的错误还有很多，明明可以把详细的错误信息输出一下，但是就不，就要使用者自己去慢慢找，是真不友好。
多余的也不吐槽了，既然在用，肯定是希望引擎越来越稳定，毕竟，谁也不想拿着一个不稳定的引擎去做自己用来生存的项目吧。
