如何在不修改原有C#代码的情况下保存异常时调用栈的原始状态？

你的需求很典型——在不触碰现有代码的前提下，用AOP捕获异常时的原始调用栈参数，但深克隆的性能开销确实让人头疼。结合你的限制（不能改源码、兼容任意C#项目），我整理了几个比深克隆更优的方案，按可行性和性能排序：

1. 动态代理替换参数（拦截修改，保留原始状态） #

这个思路是在方法进入时把原始参数存起来，用动态代理对象替换传入方法的参数，这样方法内部对参数的修改只会作用在代理上，原始参数完全保留进入时的状态，异常发生时直接用原始参数即可，不需要克隆。

实现方式： #

• 使用Castle DynamicProxy这类免费的动态代理库，在PostSharp的OnEntry方法中：
  1. 遍历方法的所有引用类型参数；
  2. 对每个可代理的类型（非密封、有虚成员）创建代理，拦截所有属性setter和可能修改状态的方法；
  3. 保存原始参数到自定义调用栈的上下文；
  4. 将方法的参数替换为代理对象（PostSharp允许修改args.Arguments）。
• 对于密封类或无法代理的类型， fallback到浅克隆+针对值类型字段的递归快照（比全深克隆快很多）。

优缺点： #

• ✅ 性能远优于深克隆：仅对引用类型做代理包装，无大量对象复制；
• ✅ 完全保留原始参数状态，不受后续修改影响；
• ❌ 无法处理密封类、非虚方法/属性的修改（需要fallback克隆）；
• ❌ 代理对象可能存在行为差异（比如GetHashCode、Equals的表现，需要额外处理）。

2. 优化版深克隆（针对性减少开销） #

如果你必须用克隆的方式，可以通过以下优化让深克隆的性能提升一个量级：

• 自定义克隆逻辑缓存：用Dictionary<Type, Func<object, object>>缓存每个类型的克隆委托，第一次通过反射生成克隆逻辑后，后续直接复用，避免重复反射开销；
• 使用高性能序列化库：比如MessagePack-CSharp（支持源生成）或System.Text.Json的源生成序列化，在OnEntry时把参数序列化为内存字节数组，异常时反序列化得到原始对象。这类序列化库的速度比反射克隆快很多，尤其是源生成模式下；
• 选择性克隆：只克隆引用类型参数，值类型参数直接复制（因为值类型是按值传递，方法内修改不会影响上层的参数值——这一点可以大幅减少克隆的范围）。

实现示例（伪代码）： #

public override void OnEntry(MethodExecutionArgs args)
{
    var originalParams = new List<object>();
    foreach (var arg in args.Arguments)
    {
        if (arg != null && !arg.GetType().IsValueType)
        {
            // 用MessagePack序列化得到原始快照
            var bytes = MessagePackSerializer.Serialize(arg);
            originalParams.Add(bytes);
        }
        else
        {
            originalParams.Add(arg); // 值类型直接保存
        }
    }
    // 将快照存入调用栈上下文
    CallStackContext.Current.Push(originalParams);
}

public override void OnException(MethodExecutionArgs args)
{
    var originalParams = CallStackContext.Current.Pop();
    foreach (var (param, original) in args.Arguments.Zip(originalParams))
    {
        if (original is byte[] bytes)
        {
            // 反序列化得到原始参数
            var originalValue = MessagePackSerializer.Deserialize(param.GetType(), bytes);
            // 记录到调用栈日志
        }
    }
}

优缺点： #

• ✅ 实现简单，兼容所有类型；
• ✅ 性能比普通反射深克隆提升3-10倍；
• ❌ 仍有序列化/反序列化的开销，但比全深克隆小很多；
• ❌ 需要处理不可序列化的类型（可以标记为跳过，或用自定义序列化逻辑）。

3. 利用CLR调试API读取原始参数值 #

这个方案完全不需要克隆或代理，直接在异常发生时从CLR的栈帧中读取方法进入时的参数原始值，但实现复杂度较高。

实现方式： #

• 利用System.Diagnostics.StackTrace和StackFrame获取调用栈的每个帧；
• 结合PDB文件（需要启用调试符号），通过System.Reflection和调试接口（比如Microsoft.Diagnostics.Runtime库）读取栈帧中参数的原始内存值；
• 这种方式不需要在OnEntry做任何操作，只在OnException时回溯调用栈获取参数。

优缺点： #

• ✅ 零前置性能开销（不在方法进入时做任何操作）；
• ✅ 完全保留原始参数状态，不受任何修改影响；
• ❌ 实现复杂，依赖PDB文件，运行环境需要调试权限；
• ❌ 对发布版本（无PDB）兼容性差。

4. 编译时代码生成（替代PostSharp的免费方案） #

如果PostSharp的付费特性用不了，可以用Roslyn分析器+代码生成在编译时自动给每个方法注入参数快照逻辑，不需要手动修改源码：

• 编写Roslyn分析器，遍历所有方法，在方法开头插入代码，保存参数的原始状态到线程本地存储；
• 异常发生时，从线程本地存储中取出对应的原始参数。

优缺点： #

• ✅ 性能最优：编译时生成的代码是原生的，无运行时反射或代理开销；
• ✅ 兼容所有类型；
• ❌ 需要配置Roslyn分析器，对项目的编译流程有一定侵入性；
• ❌ 实现复杂度较高，需要熟悉Roslyn API。

推荐方案 #

如果你的项目中大部分参数是引用类型且可代理，优先选动态代理方案；如果有大量密封类或不可代理的类型，优先选优化版深克隆方案；如果对性能要求极高且有调试符号支持，可以尝试CLR调试API方案。

内容的提问来源于stack exchange，提问作者Amon