官方一直是用很克制的语气跟你在沟通，但是并不表示你没冒犯官方。
我看了你的很多发言，负能量太重了。有些用词要是发在你自己公司内网，估计你早被开了。
说自己资深也就算了，好几次称呼别人孩子就是很明显的挑衅。
解决引擎问题是官方的义务，但是忍受和处理你的不良发言，官方就要消耗额外的精力。
想要问题顺利得到解决，需要相互尊重才对。
这句话我还是挺喜欢听的，尊重是相互的 ，如你所说
通知1(不做任何回复也不提供demo)：
label组件动态修改文字，width不会变化，参考 label string 设置内容后，获取不了width - Creator 2.x - Cocos中文社区
试试
想问一下官方，3.4以来jsb反射java静态方法，如果原生端不存在这个静态方法而客户端调用的话是会导致游戏界面卡死的。而在3.2上是不存在这个问题的，这是为了代码的严格性在3.4上的设计的还是一个bug呢?
我已经在帖子中回复了哦，使用 updateRenderData(true) 是正常的，有什么问题我们再交流~
label组件char模式不支持加粗!!!
关于这里我们为需要强制调用 updateRenderData(true) 才能够立即更新 width 的原因，是因为我们为了性能考虑，使用了 dirty 机制，会在帧末尾统一对改帧内组件的所有变更进行更新，而会导致宽度更新延迟，而在强制更新中提前更新了就可以立即获取到更新过后的宽度。
1赞
具体是用什么途径调用的？jsb.reflection.callStaticMethod还是jsb.bridge?
非常感谢你的回复，昨天心情真的糟糕透顶，我无意与官方或者论坛任何人做口头之争，关于内存的问题我这边已经找到了稳定复现的方式，官方人员请及时添加我q进行远程，一但我再次更改代码，后面将不再可以复现
使用jsb.reflection.callStaticMethod调用的，我这边是在滑动屏幕时调用Utils.hideVirtualButton();如果原生没有这个方法 界面就卡死了 但是不会崩溃 3.2上不会
非常感谢你的反馈。
顺着你的反馈我们发现了一些泄漏问题，应该是更改脚本后出现的，另外顺着这个也还发现了一些零星的小问题。
我们会在下个版本修复一下，回头会再发上来的。感谢支持吖～～～～
我觉得你们复现的还不够，我这边是浏览器运行报错才会导致的内存暴涨，而且必须重启电脑来进行释放内存，重启程序都释放不了，同时我发现跟是否关闭自动刷新资源没有任何关系，用360的内存球双击可以让你们的程序内存跌到50m不到。。。
很抱歉，我们的 char 模式因为内存考虑，暂不支持加粗，斜体和下划线。
之后会考虑进行优化，敬请期待
我加你QQ，你通过一下~
，稍等哈
昨晚1点多得时候稳定复现，真的，不是在编辑器里面报错，我是执行时候浏览器报错，导致监听7456的server程序达到300多m，昨晚已经将代码改了，如今无法稳定复现，很遗憾。。。但是现在又出现了一个新问题，那就是刚用编辑器打开项目什么都没运行就达到900M，然后这个时候只要在浏览器一运行，立马就会出现1.8g的占用内存，已经经过你们官方人员的验证，确实存在这个问题，没夸大。但不是什么时候刚打开项目都900m的，但是目前这个复现的概率还是非常的大的
疑问3：
实测无法导出预制体