项目经历了3.8.2,3.8.6，现在升级到3.8.7，但是出现了一些问题很头疼，spine资源的制作为3.8.9，部分spine资源运行后出现内存溢出的情况(如图所示)：
在web端运行会报错，无法显示该动画！在原生端就直接闪退了！
找到对应资源分别拉到3.8.6跟3.8.7，spine资源属性面板显示如下：
3.8.6：
可以这么说,spine一直是creator一直来的痛.每个版本都有对应的坑在填.填完了这个还有下一个.
难搞.都升到最新的了,去看看git上面,有没有相关同步吧.
原生上因为spine变的好不稳定，动不动就闪退，基本一查都是spine带来的内存问题！
这个问题有人出现过，论坛再找找方案
刚在论坛上看到了，似乎有人是回滚到了3.8.6的spine，不过还是没有很清晰的解决方案！引擎方有没有提供pr解决问题呢？
spine啊 就是cocos的克星，一生的杀手!
5年前 大家就一致讨论这个问题，信不信，5年后 你来这里 还是车轱辘转的问题？
难蚌了，这真没法了。我也不知道怎么搞 
我比较好奇为什么spine还能oom？是啥样的spine？我只遇到过3D粒子用了贼多粒子，然后ios直接闪退。spine还没遇到过
我也遇到过这个问题，其实有多种原因会导致这个问题。你可以看下：cocosCreator3.8 报引擎错误 RuntimeError: memory access out of bounds
我自己是timeScale的问题导致的，改掉后好了。
感谢，我这边试试看！每次升级版本都有不一样的痛的体验！！
引擎改完编译完，发现在编辑器上依然会报错，而运行环境下没有报错，但spine资源依然显示不出来，空的！参照下面两个git进行了修改：
https://github.com/cocos/cocos-engine/pull/18936
https://github.com/cocos/cocos-engine/pull/18991
运行后看到引擎代码应该是编译到的了，虽然不会报错，但我更希望能够解决spine也能正常显示，不想回头去处理spine资源！在引擎编译过程引擎是卡死的，运行后看编译后代码对应js又是改了的，所以不确定是不是引擎编译过程是不是有问题，编译时.cache目录是没有删除的！你那边解决后spine是否也能正常播放了么？
3.8.2用了挺长时间，目前很稳定
难道要回退回去？？？？3.8.2感觉内存得手动释放啊，预设destroy后即便没了引用内存也没见少！
我的问题原因跟你的可能不一样（虽然是报同一个错），我研究半天是我的ts层改动了spine的timeScale，改正就不报错了，你这个还要查查看，论坛还有其他同问题的帖子（比如：3.8.7 spine 新报错 等）。实在不行再升3.8.8试试（也有改一些spine问题）
我在3.8.7 里面也碰到过原生的spine直接报错退出的问题。
经核查是这个commit 引入的：
native/cocos/editor-support/spine/3.8/spine/SkeletonBinary.cpp 中的 readAttachment 函数的修改。
一旦碰到错误立即返回nullptr，导致某些数据有缺失的spine报错。原代码是有保护措施的，这下一同步之后就把保护措施冲掉了。
核心是上面的问题，此外，代码里面还有不少错误快速return nullptr的措施，导致不少spine出现问题。
传一个patch.zip 上来
aaa.zip (793 字节)
尝试升级到3.8.8一样的问题，虽然spine资源重新输出成json可以解决，看起来是spine读取二进制文件有问题！但没办法把那么多spine重新回炉处理！除非是可以找到批处理方式！再找找方式吧！
@song2008_2001 这个spine资源并不大，顶点也不多，为什么会有内存溢出的情况呢？尝试替换3.8.6的spine.wasm跟spine.wasm.js 后，编辑器跟溢出的情况消失，但spine动作的结束回调不触发了！可以怎么修改spine.wasm.js 里面的解析内存限制么？或者有补丁处理么？这是溢出的spine资源，一个简单的图标扫光特效！icon_vip.zip (54.0 KB)
你试一下我的修改呢？有附加patch了。用在SkeletonBinary.cpp上，改完原生的试试看有没有问题，没有问题就编译一份wasm的。
内存溢出很简单，二进制匹配不对，因为某个attachment没匹配到名字，跳过的时候没有去跳过后续该attachment的数据。导致数据读取混乱，新建了一个很大的数组。
尝试替换3.8.6的spine.wasm跟spine.wasm.js 后，编辑器跟溢出的情况消失，但spine动作的结束回调不触发了！
你这样的办法也是可以的，结束回调不触发你要看看cpp里面的事件定义enum是不是和typescript上的对应，我记得spine加过定义，不对应的话你的结束回调就会监听到其他类型事件上面去。
当然最好的还是patch一下原生库，然后再编译一份wasm。这样原生的也不会崩溃。
你是只改了SkeletonBinary.cpp还是上面的补丁都覆盖修改了？我看里面有差不多10个C++文件的修改
那个commit 是官方的，是引入问题的根源。
你看我下面那个aaa.zip，用途是还原了官方引入的bug，只改了一个文件
OK，谢谢，我试试看！
