也完善下测试用例呢？
嗯，滚轮的测试用例，我内部反馈一下。
ok 多谢修复
话说你们没问题？纹理的type设置成tiled必卡死，神了
从CocosCreator3.8.2升级到CocosCreator3.8.5之后 发现build-templates功能有问题不能和以前版本一样正常使用了
3.8.2中一直用着没问题的build-templates功能；在build-templates中定义android或者ios或者android-gp(自己定义的其他平台安卓工程目录结构)其他文件夹设置自己的内容之后，在构建原生项目时可以正常拷贝并覆盖合并替换为自己设置的自定义内容；但是升级到CocosCreator3.8.5之后就有问题了;
具体问题是：
-
<第一个问题>、不能正常拷贝自己设置的文件夹内容比如build-templates/android，不能在构建结束后覆盖合并替换build/android中对应的文件夹和内容；
-
<第二问题>、比如安卓设置了build-templates/android之后，结果构建完成之后模版内容被复制拷贝到了build/android/data/目录下，而不是拷贝到build/andriod目录下；
-
<第三问题> 升级到3.8.5之后自己定义的比如android-google、android-taptap类似这样的自定义的针对不同平台做的区分模版，在构建结束后不再自动拷贝到build文件加下了，比如原来3.8.2用着没问题时构建结束后会有build/android-google 或者build/android-taptap这样的效果了；测试了一下3.8.2以下版本包括3.8.2版本是没有问题的；
如下图：
!
另一问题是使用的3.8.2和3.8.4项目升级到3.8.5之后遇到的其他问题，如图
1赞
浏览器卡死报错，模拟器不会，重启下电脑好了
感觉非常严重呀，劝退
周末休息了，周一来吧
这种不是破坏性变更吗，为什么在小版本里上线？
为什么在更新日志和文档里只字未提？
默认勾选的话不就破坏了旧版本升级上来的代码行为了吗？
TypeScript 写进文档的语言标准（双端映射）为什么改动，尽量还是不要变成 “CocosScript” 吧…
这么久了你还信cocos还有版本定义啊？cocos要能有版本定义，要是能做到升级无忧，就不会有那么多还在用2.x的了
其实如果就为了这100来K，我感觉完全没必要，不管是web还是小游戏环境。
即便是在小游戏环境下做好引擎模块的动态引入+小游戏分包就好了。
这种做法有点搞人心态，不了解的人直接就懵了，我觉得不要为了减小包体而去引入理解上的成本。
这种做法本质和384引入的问题一样，让开发者觉得麻瓜的同时也基本带来不了提升。
我觉得，开发者想要的不是以这种方式带来的包体减小。
我觉得减少 100 来 K 挺好的，毕竟现在试玩广告只有 Cocos 可以做，我公司的 Unity 项目也只能用 Cocos 做试玩买量，试玩广告最重要的就是包体。
但不管这项功能有没有必要，时间已经花了，做了就是好事，但明明可以设计成没有破坏性变更的，却总要造成破坏性变更。
但也许其他一部分开发者很需要这个特性呢，我记得论坛上也有人要求引擎支持这个的。另外，在引擎侧可能只是减少100多K，但是，在游戏业务侧可能会减少更多呢，这是很有可能的，像一些proto的基础枚举定义，可能会在几十上百个系统中使用。
如果用了enum，还要考虑构建后可能用不了 反向映射，这开发体验太奇怪了。
你说的这种情况下按说应该开发者使用object，而不是使用enum。
如果这个优化是默认关闭的，就也还能接受 
试玩广告不了解，是H5吗，如果是H5的话，这100K经过gzip后其实就没什么区别了(这100K还是完全体下的优化结果)
微信，有包体限制，上传时计算包体时应该不会算 Gzip 后的。
听引擎组的描述，感觉应该只做了引擎代码部分的优化。
最好的设计还是支持 const enum 语法，然后引擎部分的代码再单独提供选项控制默认是否内联，并提供白名单设置让用户可以取消某些内联，这样最好用。
感谢反馈，你可以暂时先到构建任务列表，任意设置一个为正常构建，然后再新建任务
这个具体看引擎是否支持，后续如果引擎支持的会加上