.Net 6使用FakeItEasy时伪造方法出现异常含0随机Guid问题

你观察到的「前半段随机变化、后半段全为0」的Guid，本质是参数绑定错位时读取到栈上脏内存的典型特征，不是传入的testGuid被篡改，也不是FakeItEasy随机生成的值，这类问题的触发逻辑和排查方向如下：

• 根因解释：这类半零Guid完全符合内存错位读取的特征：前几个字节是栈上其他临时值（比如方法返回地址、CancellationToken内部标记、其他局部变量），受系统ASLR（地址空间布局随机化）影响每次运行值都会变；后半段对应的内存位置没有被写入有效数据，全是默认0值，因此既不会出现全0的Guid.Empty，也不会匹配你传入的固定testGuid。
• 最常见触发场景：ReturnsLazily配置的委托签名，和被伪造方法的实际签名不匹配
  重点检查FooFunctionAsync的完整方法签名，不要忽略隐式/带默认值的参数：
  1. 异步方法最容易漏的是默认参数CancellationToken，很多仓储类异步方法签名是Task FooFunctionAsync(Guid id, CancellationToken ct = default)，编译后调用方必须传入该参数（默认值由编译器自动填充），FakeItEasy实际会收到2个入参，你配置的单参数Guid委托无法正确匹配参数位置，就会出现读内存错位。
  2. 检查委托返回值是否匹配：如果FooFunctionAsync返回Task/Task<T>，你的委托需要返回对应类型的Task（比如加async关键字、显式返回Task.CompletedTask），否则FakeItEasy会自动匹配参数数量最接近的重载，不会抛出签名不匹配的错误，最终导致参数绑定错位。
• 「同代码同事运行正常、你本地异常」的原因
  这类内存错位问题的表现和运行环境强相关，核对以下配置差异即可：
  1. 本地NuGet引用的FakeItEasy版本是否和同事一致：旧版本FakeItEasy对不匹配签名的容错逻辑、参数绑定规则存在差异，部分版本不会对参数数量不匹配的配置抛出告警。
  2. 项目生成配置是否一致：重点核对平台目标（x86/x64/Any CPU）、.NET SDK版本、是否启用Nullable上下文，这些配置会直接影响栈内存布局，你本地因为内存布局刚好错位读到脏值，同事的环境下栈内存布局刚好让错位位置读到了正确的Guid值，属于偶发的「巧合正常」，不代表代码本身没有问题。
• 快速验证方法
  临时把ReturnsLazily的配置改成接收完整调用参数的形式，直接断点查看实际传入的参数列表，就能快速定位问题：

  A.CallTo(() => fooRepo.FooFunctionAsync(A<Guid>.Ignored))
   .ReturnsLazily(call => 
   {
       // 断点查看call.Arguments的数量和每个值的类型
       var passedArgs = call.Arguments.ToArray();
       fooInternalObject.DoSomething((Guid)passedArgs[0]);
       return Task.CompletedTask;
   });
  

  如果断点看到passedArgs长度不是1，就能直接定位到是方法签名存在你没注意到的额外参数。

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