自定义ECS获取组件时引用内存地址异常，返回垃圾数据问题排查

你的核心问题是逻辑索引错误——你返回的是存储组件数组的components数组本身的元素引用，而非目标组件数组内的对应元素引用，这直接导致内存地址解析异常，出现高位全0/全F的情况。

具体错误点 #

1. 字段名笔误：代码里ref Array array = ref Components[cType.ID];中的Components是大写，而结构体的私有字段是components（小写），这会导致编译错误或访问错误的成员。
2. 核心逻辑错误：返回语句return ref components[entityID];完全偏离目标——你索引的是Array[]类型的components数组，拿到的是某个Array对象的引用地址，而不是你需要的T[]数组里的第entityID个组件元素的地址。这就是为什么内存地址后半段正确（对象引用的低位）但高位异常（64位系统下对象引用的标记位），最终读到垃圾数据。
3. readonly修饰符冲突：readonly方法内的结构体字段是只读的，虽然数组是引用类型可以修改内部元素，但返回ref T允许外部修改元素，保留readonly可能引发语义混淆，建议移除。

修复后的代码 #

public struct Block
{
    private Array[] components;

    unsafe public ref T Get<T>(int entityID)
    {
        ref ComponentType cType = ref ComponentType.GetInfo<T>();

        // 修正字段名大小写，获取对应类型的组件数组
        ref Array array = ref components[cType.ID];
        T[] cmpArray = Unsafe.As<T[]>(array);

        // 返回目标数组内指定实体ID的组件引用
        return ref cmpArray[entityID];
    }
}

补充说明 #

• 内存地址异常的本质：之前错误地取到了Array对象的引用地址，而非数组内部元素的连续内存地址。64位系统中，对象引用的高位会带有 runtime 的标记信息（全0或全F），而组件元素的地址是数组堆内存内的偏移地址，所以会出现你观察到的地址后半段匹配但高位异常的现象。
• Unsafe.As的安全前提：必须保证components[cType.ID]确实是T[]类型，否则会引发类型错误。建议在ComponentType.GetInfo<T>()的逻辑中确保类型ID与数组类型严格对应，或者添加类型检查避免崩溃。
• ref关键字的作用：返回ref T让你直接拿到组件元素的内存引用，修改该引用的值会直接修改数组内的原始数据，这正是ECS追求的高效内存访问模式。

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