咱们先把你的问题拆成两部分：为啥必须排除这俩程序集，还有排除后对性能的影响，顺便解释下你遇到的那个内存错误。

一、为啥这俩程序集必须从AOT流程里排除？ #

你碰到的RuntimeError: memory access out of bounds本质是AOT编译器在处理这两个程序集时“卡壳”了，原因在于：

• Uno.Core：这是Uno平台的核心基础库，里面塞满了跨平台适配的动态逻辑、反射相关的工具类，还有不少Uno特有的类型扩展。这些代码很多是运行时才能确定执行路径的，而AOT是提前把代码编译成Wasm字节码，没法处理这种动态特性——强行编译就会生成有逻辑漏洞的Wasm代码，运行时直接触发内存越界。
• System.Core：作为.NET的核心程序集，它包含LINQ、泛型等基础功能，但部分代码依赖JIT编译的动态生成逻辑（比如某些泛型类型的特殊实例化）。在InterpreterAndAOT混合模式下，AOT编译器尝试静态编译这些部分时，会和解释器的运行逻辑冲突，最终导致内存访问错误。

简单说：这俩程序集里有太多AOT“搞不定”的动态代码，不排除的话，编译出来的Wasm根本没法正常跑。

二、排除后对性能有啥影响？ #

InterpreterAndAOT是混合模式：一部分代码AOT编译成Wasm（执行速度快），另一部分靠解释器运行（速度慢，但兼容动态逻辑）。排除这两个程序集后：

• 会变慢的部分：这俩程序集里的所有代码都会走解释器执行，解释器的速度大概是AOT编译代码的1/5到1/10。如果你的应用大量用Uno.Core的核心API（比如UI绑定、跨平台状态管理），或者频繁调用System.Core里的复杂LINQ查询、泛型操作，这些场景会明显感觉到卡顿。
• 不受影响的部分：你自己写的业务代码、其他能被AOT正常编译的第三方库，依然会以AOT的方式运行，这部分性能和正常AOT模式没区别。
• 实际体验参考：如果是普通的表单、展示类应用，这个性能损耗大概率感知不明显；但如果是游戏、大数据处理这类性能敏感的应用，卡顿可能会比较突出。

三、后续的优化方向 #

• 现阶段：排除策略是必须的，能保证应用正常运行。你可以尽量减少对这两个程序集里高频解释器代码的依赖——比如缓存LINQ查询结果、避免不必要的反射操作，来降低性能损耗。
• 长期：关注Uno平台的官方更新，他们一直在优化AOT兼容性，后续版本大概率会修复这两个程序集的编译问题；另外也可以试试纯Interpreter模式（启动慢但兼容性拉满），或者等.NET官方对Wasm AOT的支持进一步完善。

内容的提问来源于stack exchange，提问作者dp901