struct在多线程中默认值拷贝、非线程安全，操作副本不影响原值；class支持引用共享但需手动同步，锁对象须稳定；异步中struct字段await后被重拷贝，class则保持同一实例。
struct 在多线程中默认是“值拷贝”，不是线程安全的共享变量
你不能指望多个线程同时读写同一个 struct 实例还能保持一致——因为只要把它赋给另一个变量、传进方法、或者放进数组/集合，就会触发完整值拷贝。这意味着每个线程操作的其实是独立副本，改了也影响不到别人。
常见错误现象：Interlocked 无法直接用于 struct 字段（除非是单个 int/long 等支持原子操作的字段），lock(this) 对 struct 无效（this 会装箱成新对象，每次 lock 锁的都不是同一个引用）。
- 把
struct当作共享状态容器（比如用它存计数器、标志位）极易出错 - 在
ConcurrentQueue或ConcurrentDictionary中使用可变struct，可能因复制导致逻辑错乱 - 避免在
async方法中捕获可变struct的字段到闭包里，容易读到过期值
class 天然支持引用共享，但不等于线程安全
class 实例默认通过引用传递，多个线程可以真正读写同一块堆内存。但这只是“能共享”，不是“安全共享”。你需要自己加同步机制。
典型误用场景：多个线程并发调用 list.Add(item)（List 非线程安全）、或读写同一个 class 的公共字段而没加锁。
- 不要依赖
class的引用语义来自动获得线程安全 - 对共享字段读写，优先用
Interlocked（适用于int/long/bool/IntPtr等） - 复杂状态变更建议用
lock或ReaderWriterLockSlim，锁对象必须是稳定的引用（如私有readonly object _sync = new()） - 避免锁
this、typeof(T)或字符串字面量，容易引发死锁或意外争用
struct 和 class 在 async/await 中的行为差异很关键
在异步方法中，struct 字段若被捕获进状态机（state machine），会在每次 await 后被重新拷贝；而 class 字段始终指向同一实例。
public struct Counter
{
public int Value;
}
public class CounterClass
{
public int Value;
}
public async Task UseStruct()
{
var s = new Counter { Value = 1 };
await Task.Delay(1);
s.Value++; // 这里的 s 是 await 前拷贝的副本，原始栈帧中的 s 已不可达
}
public async Task UseClass()
{
var c = new CounterClass { Value = 1 };
await Task.Delay(1);
c.Value++; // 正确修改堆上那个实例的 Value
}
这个差异常被忽略，尤其在自定义 ValueTask 或手动实现 IAsyncStateMachine 时，struct 的生命周期和拷贝行为会直接影响状态一致性。
什么时候该选 struct，什么时候必须用 class？
选 struct 只应基于明确的设计契约：小、不可变、值语义清晰（如 Point、DateTime、Guid）。多线程下更需谨慎——除非你明确需要无锁复制语义（比如做快照、日志采样），否则别让它承载可变共享状态。
class 是默认选择，尤其涉及生命周期管理、事件注册、异步协作或多线程协作时。即使性能敏感，也优先用 Memory、Span 或池化（ArrayPool）优化，而不是强行用可变 struct 替代。
- 可变
struct+ 多线程 ≈ 隐形时间炸弹 -
lock、Interlocked、Channel这些机制都是围绕引用类型设计的，对struct支持有限且易出错 - 调试时看到
struct字段值“突然不变”或“改了又恢复”，大概率是拷贝掩盖了修改意图
最麻烦的不是写错，而是错得不报错、只在高并发下偶发失效。