其实也不光是物理引擎，就是方方面面
同一套代码，构建到不同的平台
代码的行为，时序，等等
不同的平台，得到的最终表现不一致
定位问题时也没有头绪
是本身引擎就是存在这些问题
需要针对不同平台不同实现
还是说构建、出包的过程中
某些行为会导致这种不一致性
如果是动画有表现上的差异(快慢) 我觉得是正常的， 像王者也会有相同的问题
关键在于数据的决定性的事件上
技能发动时机， 命中结算时机是依赖服务端逻辑帧第几帧到几帧之间的处理
像这种数据处理肯定是基于定点数进行运算
不是引擎存在这问题， 是本身浮点数都有这问题， 你用unity没有定点数库试试， 一様出现不同平台结果对不上。
如果你不同平台不同设备只想依赖自身update去处理决定性，那我想没有一款游戏引擎可以满足你，因为这是你从技术方案上已经有问题
没太明白
你的意思是，所有的这些都是基于浮点数机制的不同导致的差异吗
或者我说一说我实际遇到的一些问题
包括但不限于
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要强