没太明白
你的意思是，所有的这些都是基于浮点数机制的不同导致的差异吗
或者我说一说我实际遇到的一些问题
包括但不限于
1.组件的生命周期
2.资源的加载
3.渲染顺序
4.异步调用(promise,async,await)
等等这些，在我历来开发的项目中
或多或少会出现以上之中的一个
但也不是每个项目都会遇到
给我的感觉就像是，不容平台中，程序中运行时的时序，并不统一，也没有参考性
如果是因为不同平台中浮点数的处理机制的问题
有没有可供参考的处理方案
或在游戏设计过程中，该如何尽可能的避免或绕开，其造成的影响
- 组件生命周期 ， 资源加载跟平台与设备的I/O能力有关， 不同平台底层处理不一様， 但这在游戏项目开发中完全不是问题，这种I/O产生异步不同情况完全可以依赖项目在技术设计方案上去避开（如资源提前加载， 所有人都进场景后上报服务端， 服务端下发正式开始游戏)
- 你举列渲染顺序如何影响游戏？
- 浮点数问题是计算机基础知识，你可以自己上网查或GPT一下
- 至于不同平台有一点不同， 就是cc打包native后部分代码是由c++层托管执行，采用opengl渲染，所以某些在web平台正常运行在native不能运行
给我的感觉就像是，不容平台中，程序中运行时的时序，并不统一，也没有参考性
如果是因为不同平台中浮点数的处理机制的问题
每个平台底层不一様， 但这不重要， 关键是你应用层的表现是否一様， 用户之间同步是否致就可以
以上你要避开， 自己去看书， 做研究， webgl与opengl差别， android平台/ios平台app开发书籍
十分感谢，您的回答 
rapier.js无法在原生ios使用，会提示[WARN]: JS: WebAssembly is not supported!
养成查询h5 api 支持的版本
WebAssembly, 至少要ios 11 才能支持。 报错写WebAssembly no support ， 就是説你的浏览器不支持， window作用域下没有WebAssembly这东西。
我的是ios 16，但我不是用ios的浏览器打开游戏的，我是打包成ios原生的app和安卓原生的app，安卓原生的app在游戏里用v8引擎是能正常运行 rapier，但ios原生的引用的javascriptcore则不支持WebAssembly。我试过部署到web上在 ios的浏览器safri里打开是能正常运行rapier的。我想问一下你有试过直接把rapier打包成ios的原生app吗？
我负责的都是基于自家app的webview进行游戏， 但就算ios webview 也是使用了javascriptcore， 只要是ios 11以上都是能跑webassembly，因为jscore是在v11开始支持webassembly 1.0, 如果你是使用cocos 提供的打包原生后无法使用webassembly， 那你就要问问官方是否要采用另一种方式去实例webassembly, 如果确认自身的jscore能支持webassembly， 但运行时不行可以考虑像桥接一様在原生层注入Webassembly 方法到 window作用域下
CocosCreator 在iOS App上也是用的V8引擎驱动JS，V8引擎自带的WASM和TurboFan深度绑定关系，而TurboFan直接关联jit
但因为iOS审核限制限制了不能开启jit，所以TurboFan、v8的WASM都不能启用，也就是webassembly is undefined，这个其实有解决办法，静候佳音
iOS上面也是可以运行WASM，但只能在解释器模式下，苹果钦定的JavaScriptCore引擎，最新版本是带了一个WASM解释器
解释器模式运行，性能远低于JIT模式WASM
原来是这样，我想问一下，你说的有解决办法，是指什么办法，能简单说一下吗，我想去尝试一下。我目前想试的一个方法是看看能不能把rapier转成asm.js，就像cocos creator现在打包ios原生app如果box2d选用了wasm但实际打出来的是asm.js。这样起码rapier在能原生 ios用。但好像没找到有这样的案例
你的方法是指自行升级V8到12.X，然后改成非JIT模式？
是的，微软给v8贡献了一个解释器模式的WASM，可在非jit模式下运行，v8版本好像得12.x以上才有
是要加什么参数才能启用解释器模式的WASM？我看了引擎源码，它默认已经加了一个非jit的参数 flags.append(" --jitless");
然后我看原来cocos的开发者也编译了一个v8的12.6.228.49的版本出来
https://github.com/forkrp/test-v8/releases/tag/12.6.228.49-2
详细信息参考，我还没试过
[DrumBrake: a Wasm Interpreter for V8 - Google Docs]
(https://docs.google.com/document/d/1OIJ4Sv2XfTlI5NmTS1QI8v8wPL0LUT5s1W2D9OlJmMc/preview?tab=t.0#heading=h.2hff7nffvheq)
该文档中说明了在iOS的非JIT模式下开启WASM的性能对比
通过node --wasm-jitless xxx.js，可以快速测试得出结论WebAssembly.instantiate是可用的，只是没有了jit
那么，其实是否可以考虑将Cocos中的–jitless换成–wasm-jitless呢？
所以我理解是其实关闭v8_enable_drumbrake的情况下构建，
打开–wasm-jitless也只是能保证有WebAssembly模块可以使用，
对性能没有任何帮助？
开启wasm不会提升解释器环境的js性能，两者独立，增加v8_enable_drumbrake是为了保证iOS环境也能用wasm，做到跟android一致。合理使用，wasm的性能都比js要强
我想wasm环境支持应该是V8_ENABLE_WEBASSEMBLY控制？
但Cocos使用–jitless导致wasm丢失支持（node.js使用–jitless也会导致wasm无法使用）？
所以收敛为–wasm-jitless更小范围以保证ios审核问题同时可执行wasm，不考虑执行性能问题？
寄
翻到v8里的一条说明，不用纠结了