struct在高并发下更快因其值类型特性，分配于栈或内联，免GC；class为引用类型，堆分配加剧GC压力与锁竞争。但过大struct或频繁值传递、逃逸至堆时反而更慢。
struct 在高并发下为什么比 class 更快
因为 struct 是值类型，分配在栈上（或内联在容器中），不经过 GC；而 class 是引用类型，每次 new 都触发堆分配，高并发时会快速产生大量短生命周期对象，加剧 GC 压力——尤其是 Gen0 频繁回收，直接拖慢吞吐量。
- 多个线程同时
new MyClass()→ 多个堆内存请求 → 竞争 GC heap lock（.NET 6+ 改进但仍有开销） - 同一线程内循环创建
MyStruct→ 栈指针偏移即可，无同步、无跟踪、无 finalizer 开销 - 结构体被用作字典键、队列元素、Span
内容时，避免装箱和指针间接访问
什么时候 struct 反而更慢
当结构体过大（通常 >16 字节）或频繁按值传递时，复制成本会反超引用传递
struct 被当作方法参数传入 10 万次/秒，CPU 缓存带宽和寄存器压力会显著上升。
- 方法签名含
MyLargeStruct s（而非ref MyLargeStruct s）→ 每次调用复制全部字段 - 放进
List→ 扩容时整块内存 memcpy，比List的指针数组复制重得多 - 被闭包捕获或用在 async 方法中 → 可能被提升为堆分配（.NET 5+ 对 ref struct 有严格限制，普通 struct 也可能逃逸）
高并发典型场景下的实测建议
以高频消息处理（如 WebSocket 心跳包解析、订单快照生成）为例，优先用 struct，但必须满足「小、不可变、无引用字段」三原则：
public readonly struct OrderSnapshot
{
public readonly long OrderId;
public readonly decimal Price;
public readonly int Status;
public readonly DateTime Timestamp;
public OrderSnapshot(long id, decimal price, int status, DateTime ts)
{
OrderId = id;
Price = price;
Status = status;
Timestamp = ts;
}
}
- 字段全用
readonly，避免意外修改引发线程安全问题 - 不含
string、List、object等引用类型字段（否则仍需 GC 管理） - 构造函数不调用虚方法、不触发静态构造器或复杂初始化逻辑
- 若需序列化，用
Span+BinaryPrimitives直接写入，避开JsonSerializer.Serialize的反射开销
容易被忽略的陷阱：struct 的线程局部性假象
很多人以为 struct 天然线程安全，其实不然。多个线程操作同一个可变 struct 实例（比如共享在 static 字段或 ConcurrentQueue 中）会导致读写撕裂——因为 struct 复制是逐字段进行的，非原子。
-
public static MyMutableStruct SharedData;→ 线程 A 写SharedData.X，线程 B 同时读整个SharedData，可能拿到 X 新值 + Y 旧值 - 即使加了
lock，若锁粒度覆盖不到所有字段访问路径，仍可能出错 - 正确做法：要么彻底不可变（
readonly struct），要么改用class+ 显式同步，或者用Interlocked操作单个字段
