C#中浅拷贝（如MemberwiseClone）仅复制引用，值类型字段被复制，引用类型字段共享同一对象；深拷贝推荐用System.Text.Json序列化反序列化，安全高效，适用于大多数POCO类。
浅拷贝只是复制引用，不是复制对象本身
在 C# 中，MemberwiseClone() 默认只做浅拷贝：它会为新对象分配内存，但对所有字段（尤其是引用类型）仅复制地址值。这意味着原对象和副本共享同一块堆内存中的引用对象。
常见错误现象：objA.ListProperty.Add(item) 后，objB.ListProperty 也出现该 item —— 因为两者指向同一个 List 实例。
- 值类型字段（如
int、struct）会被真正复制一份 - 引用类型字段（如
string、List、自定义类）只复制引用，不复制所指对象 -
string是特例：虽是引用类型，但不可变，行为上接近值语义，常被误认为“深”
JSON 序列化是最简单可靠的深拷贝方案
用 System.Text.Json 或 Newtonsoft.Json 序列化再反序列化，天然绕过引用共享问题，适合大多数 POCO 类型。
注意前提：类必须是可序列化的（public 读写属性、无循环引用、无不可序列化字段如 FileStream、Delegate 等）。
var clone = JsonSerializer.Deserialize( JsonSerializer.Serialize(original));
- 无需实现
ICloneable，也不依赖[Serializable] -
System.Text.Json性能更好，但默认忽略私有字段；可用JsonSerializerOptions.IncludeFields = true（.NET 6+）或改用JsonPropertyName显式控制 - 遇到
DateTimeOffset、Dictionary等类型时，确保JsonSerializerOptions配置兼容（例如PropertyNameCaseInsensitive = true）
手动实现深拷贝需递归处理每个引用字段
当对象含非序列化成员（如数据库连接、事件委托、IntPtr）、或性能极度敏感（JSON 序列化开销大）时，才考虑手写深拷贝逻辑。
关键点不是“重写 Clone()”，而是识别哪些字段需要 new、哪些可复用、哪些应跳过。
- 对每个引用字段，判断是否需要深拷贝：例如
Logger实例通常全局共享，不应复制；而Configuration对象一般要复制 - 避免无限递归：检测循环引用（如父子双向引用），可用
HashSet缓存已处理对象 - 不要直接调用
MemberwiseClone()再逐字段覆盖——它无法处理嵌套结构，且易漏字段
BinaryFormatter 已弃用，别再用它做深拷贝
.NET Core 5+ 完全移除了 BinaryFormatter 的运行时支持，即使代码编译通过，运行时也会抛出 PlatformNotSupportedException。
错误示例（不要复制）：
var formatter = new BinaryFormatter();
using (var stream = new MemoryStream())
{
formatter.Serialize(stream, obj);
stream.Position = 0;
return (T)formatter.Deserialize(stream); // ⚠️ 运行时报错- 它要求所有类型标记
[Serializable]，且存在严重安全风险（反序列化任意类型） - 跨版本兼容性差，不同 .NET 版本间可能无法反序列化
- 替代方案明确：优先选 JSON，次选
ISerializable+ 自定义序列化，或手写构造逻辑
实际项目中，90% 的深拷贝需求用 JsonSerializer 就够了；剩下 10% 要么是性能瓶颈点（得压测确认），要么是特殊资源管理场景（得仔细设计生命周期）。别为了“看起来更底层”而绕开简单可靠的方式。
