我知道，这个问题和答案在这里停留了一段时间，下面不是很好的答案，而是观察，最近我在检查是否确实没有克隆隐私（如果没有，我就不会是我自己了；）时，我很高兴地复制了粘贴的@johnc更新的答案。

我简单地制作了自己的扩展方法（这几乎是上述答案的复制粘贴）：

public static class CloneThroughJsonExtension
{
    private static readonly JsonSerializerSettings DeserializeSettings = new JsonSerializerSettings { ObjectCreationHandling = ObjectCreationHandling.Replace };

    public static T CloneThroughJson<T>(this T source)
    {
        return ReferenceEquals(source, null) ? default(T) : JsonConvert.DeserializeObject<T>(JsonConvert.SerializeObject(source), DeserializeSettings);
    }
}

并天真地放弃了这样的课程（事实上，有更多这样的课程，但它们是无关的）：

public class WhatTheHeck
{
    public string PrivateSet { get; private set; } // matches ctor param name

    public string GetOnly { get; } // matches ctor param name

    private readonly string _indirectField;
    public string Indirect => $"Inception of: {_indirectField} "; // matches ctor param name
    public string RealIndirectFieldVaule => _indirectField;

    public WhatTheHeck(string privateSet, string getOnly, string indirect)
    {
        PrivateSet = privateSet;
        GetOnly = getOnly;
        _indirectField = indirect;
    }
}

代码如下：

var clone = new WhatTheHeck("Private-Set-Prop cloned!", "Get-Only-Prop cloned!", "Indirect-Field clonned!").CloneThroughJson();
Console.WriteLine($"1. {clone.PrivateSet}");
Console.WriteLine($"2. {clone.GetOnly}");
Console.WriteLine($"3.1. {clone.Indirect}");
Console.WriteLine($"3.2. {clone.RealIndirectFieldVaule}");

结果是：

1. Private-Set-Prop cloned!
2. Get-Only-Prop cloned!
3.1. Inception of: Inception of: Indirect-Field cloned!
3.2. Inception of: Indirect-Field cloned!

我整个人都在想：什么……所以我抓起Newtonsoft.Json Github repo，开始挖掘。结果是：当反序列化一个恰好只有一个ctor且其参数名匹配（不区分大小写）公共属性名的类型时，它们将作为这些参数传递给ctor。在这里和这里的代码中可以找到一些线索。

要旨

我知道这不是很常见的情况，示例代码有点滥用，但嘿！当我检查灌木丛中是否有龙在等着跳出来咬我的屁股时，我大吃一惊；）

我也通过反思看到了它的实现。基本上，有一种方法可以遍历对象的成员，并将它们适当地复制到新对象中。当它到达引用类型或集合时，我认为它对自己进行了递归调用。反射是昂贵的，但效果很好。

我对当前的答案做了一些基准测试，发现了一些有趣的事实。

使用BinarySerializer=>https://stackoverflow.com/a/78612/6338072

使用XmlSerializer=>https://stackoverflow.com/a/50150204/6338072

使用Activator.CreateInstance=>https://stackoverflow.com/a/56691124/6338072

这些是结果

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1734 (1909/November2019Update/19H2)

Intel Core i5-6200U CPU 2.30GHz（Skylake），1个CPU，4个逻辑核和2个物理核[主机]：.NET Framework 4.8（4.8.4400.0），X86 LegacyJIT默认作业：.NET Framework 4.8（4.8.4400.0），X86 LegacyJIT

这个方法为我解决了问题：

private static MyObj DeepCopy(MyObj source)
        {

            var DeserializeSettings = new JsonSerializerSettings { ObjectCreationHandling = ObjectCreationHandling.Replace };

            return JsonConvert.DeserializeObject<MyObj >(JsonConvert.SerializeObject(source), DeserializeSettings);

        }

这样使用：MyObj a=DeepCopy（b）；

由于这个问题的几乎所有答案都不令人满意，或者在我的情况下显然不起作用，我编写了AnyClone，它完全通过反思实现，并解决了这里的所有需求。我无法让序列化在结构复杂的复杂场景中工作，IClonable也不太理想——事实上，它甚至没有必要。

使用[IgnoreDataMember]、[NonSerialized]支持标准忽略属性。支持复杂集合、不带setter的财产、只读字段等。

我希望这能帮助其他遇到我同样问题的人。

简单的答案是从ICloneable接口继承，然后实现.clone函数。克隆应该按成员进行复制，并对任何需要它的成员执行深度复制，然后返回结果对象。这是一个递归操作（它要求您要克隆的类的所有成员都是值类型或实现ICloneable，并且它们的成员是值类型或者实现IClonea，依此类推）。

有关使用ICloneable克隆的详细说明，请参阅本文。

长篇大论的答案是“视情况而定”。正如其他人所提到的，ICloneable不受泛型支持，需要对循环类引用进行特殊考虑，并且实际上被一些人视为.NET Framework中的“错误”。序列化方法取决于对象是否可序列化，而这些对象可能不可序列化，并且您可能无法控制。对于哪种做法是“最佳”做法，社会上仍有很多争论。事实上，没有一个解决方案是适用于所有情况的一刀切的最佳实践，就像ICloneable最初被解释的那样。

请参阅本开发者角文章，了解更多选项（归功于Ian）。