浅拷贝只是复制引用，不是复制对象本身
在 C# 中，
MemberwiseClone()默认只做浅拷贝：它会为新对象分配内存，但对所有字段（尤其是引用类型）仅复制地址值。这意味着原对象和副本共享同一块堆内存中的引用对象。
常见错误现象：
objA.ListProperty.Add(item)后，
objB.ListProperty也出现该
item—— 因为两者指向同一个
List<t></t>实例。 值类型字段（如
int、
struct）会被真正复制一份 引用类型字段（如
string、
List<t></t>、自定义类）只复制引用，不复制所指对象
string是特例：虽是引用类型，但不可变，行为上接近值语义，常被误认为“深”
JSON 序列化是最简单可靠的深拷贝方案
用
System.Text.Json或
Newtonsoft.Json序列化再反序列化，天然绕过引用共享问题，适合大多数 POCO 类型。
注意前提：类必须是可序列化的（public 读写属性、无循环引用、无不可序列化字段如
FileStream、
Delegate等）。
var clone = JsonSerializer.Deserialize<MyClass>(
JsonSerializer.Serialize(original));
无需实现 ICloneable，也不依赖
[Serializable]
System.Text.Json性能更好，但默认忽略私有字段；可用
JsonSerializerOptions.IncludeFields = true（.NET 6+）或改用
JsonPropertyName显式控制 遇到
DateTimeOffset、
Dictionary<k></k>等类型时，确保
JsonSerializerOptions配置兼容（例如
PropertyNameCaseInsensitive = true）
手动实现深拷贝需递归处理每个引用字段
当对象含非序列化成员（如数据库连接、事件委托、
IntPtr）、或性能极度敏感（JSON 序列化开销大）时，才考虑手写深拷贝逻辑。
关键点不是“重写
Clone()”，而是识别哪些字段需要 new、哪些可复用、哪些应跳过。 对每个引用字段，判断是否需要深拷贝：例如
Logger实例通常全局共享，不应复制；而
Configuration对象一般要复制 避免无限递归：检测循环引用（如父子双向引用），可用
HashSet<object></object>缓存已处理对象 不要直接调用
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% 要么是性能瓶颈点（得压测确认），要么是特殊资源管理场景（得仔细设计生命周期）。别为了“看起来更底层”而绕开简单可靠的方式。
