不能靠强转实现“无损还原为基本类型数组”来加速ORM反射，因强转仅改变编译时视图而不解析数据；真正瓶颈在于属性遍历、字符串匹配和装箱，有效优化应使用MemoryMarshal.Cast零拷贝转换或启用表达式树缓存。
不能靠强转实现“无损还原为基本类型数组”来加速 orm 反射。
强转不等于类型还原
强转（如 (int[])obj）只是告诉编译器“我确信这个 object 实际装的是 int[]”，它不执行任何数据解析或结构重建。如果 obj 实际是 List<int>、byte[]、JObject 或数据库返回的 DataRow，直接强转 int[] 会立刻抛 InvalidCastException —— 这不是性能问题，而是逻辑错误。
ORM 反射慢的真正瓶颈不在类型转换
典型 ORM（如 EF Core、Dapper）中，反射开销主要来自：
- 运行时遍历属性并调用 getter/setter
- 动态创建映射委托（尤其首次查询）
- 字段名与属性名匹配的字符串比较
- 值类型装箱（如从 DataReader 读取 int 时返回 object）
把 object 强转成数组解决不了其中任何一个。
真正有效的加速方式
若你拿到的是已知结构的原始数据（比如 byte[] 或 Span<byte>），且目标是填充 int[]：
- 用 MemoryMarshal.AsBytes + MemoryMarshal.Cast 零拷贝视图转换（需 unsafe 或 Span 支持）
- 用 System.Buffers.BinaryPrimitives 逐个解析（适合变长/非对齐场景）
- 在 ORM 层启用编译时表达式树缓存（EF Core 7+ 默认开启）或使用 Dapper 的强类型泛型查询
- 避免 object 中间层：DataReader 直接调用 GetInt32() 而非 GetValue()
警惕“伪优化”陷阱
例如写 var arr = obj as int[] ?? throw new InvalidCastException(); 看似安全，但前提是 obj 必须是托管堆上真正的 int[] 对象。ORM 查询结果几乎从不直接返回基本类型数组 —— 它们返回的是实体对象、匿名类型、Dictionary<string, object> 或自定义记录类。强行要求数组结构，反而会破坏抽象层，增加维护成本。
