不用序列化实现深拷贝，唯一靠谱的路径是手写反射递归克隆，但必须绕过memberwiseclone、处理循环引用、跳过不可复制成员（如event、intptr、readonly字段），且无法全自动适配所有类型——它不是“写一次就通用”，而是“为特定对象图定制”。
直接说结论：不用序列化实现深拷贝，唯一靠谱的路径是手写反射递归克隆，但必须绕过 MemberwiseClone、处理循环引用、跳过不可复制成员（如 event、IntPtr、readonly 字段），且无法全自动适配所有类型——它不是“写一次就通用”，而是“为特定对象图定制”。
为什么不能直接用 MemberwiseClone + 反射凑合？
很多人试过遍历字段，对引用类型字段调用 MemberwiseClone，结果还是浅的。因为 MemberwiseClone 本身不递归，它只做一层位拷贝；而反射只是帮你拿到字段，没解决“怎么安全克隆这个字段值”的问题。
- 遇到
string、DateTime这类不可变类型，直接赋值没问题 - 遇到
List<t></t>，new List<t>(src)</t>是浅的（元素引用未变）；若T是引用类型，还得递归克隆每个T - 遇到
Dictionary<k v></k>，不能只 new 一个空字典再 foreach Add —— 需要深拷贝 Key 和 Value（尤其K是自定义类时） - 遇到
event字段，反射能读到，但无法赋值（编译器生成的 backing field 不公开），强行设会抛异常
手写反射深拷贝必须处理的三个核心逻辑
真正能跑通的反射方案，不是“遍历字段然后 clone”，而是带状态、带缓存、带类型策略的递归过程。
- 用
Dictionary<object object></object>缓存已克隆的对象实例，检测并终止循环引用（比如 A→B→A） - 对每个字段值做类型分发：
if (value is IList list)→ 逐项克隆后 new 同类型列表；if (value is IDictionary dict)→ 克隆 Key/Value 后重建字典 - 跳过
FieldInfo.IsInitOnly（即readonly）、FieldInfo.Attributes.HasFlag(FieldAttributes.NotSerialized)、以及委托或event对应的编译器生成字段（名字含）
性能和兼容性现实约束
反射深拷贝在 .NET 6+ 上比以前快，但依然有硬伤：
- 每次访问字段都要
FieldInfo.GetValue/SetValue，比直接属性访问慢 10–50 倍，大对象反复调用明显卡顿 - 无法处理
unsafe类型、ref struct、含Span<t></t>或Memory<t></t>的类——这些类型根本不支持反射赋值 - 泛型类型构造（如
Dictionary<string person></string>）需用MakeGenericType动态构造，出错时堆栈难读 - 若原始对象含
IDisposable字段（如FileStream），反射克隆后会得到两个对象指向同一资源，后续Dispose会崩
最常被忽略的细节：构造函数与初始化逻辑
反射克隆不调用任何构造函数，也不触发属性 setter。这意味着：
- 如果类依赖构造函数初始化某些字段（比如
_cache = new ConcurrentDictionary()），反射出来的副本里该字段仍是null - 如果属性有 backing field 且 setter 里做了验证或副作用（比如
set { _name = value?.Trim(); Notify(); }），反射绕过 setter，直接写 field，就丢了逻辑 - 静态字段、线程局部存储（
[ThreadStatic]）完全不会被复制，但新手常误以为“反射扫到了就算”
所以，所谓“无序列化手写深拷贝”，本质是放弃通用性，换取对特定对象结构的精确控制——它适合 DTO 层固定模型，不适合混杂业务逻辑、生命周期管理、或第三方库类型的复杂实体。
