Mono Mac环境WCF客户端调用Close()超时 同代码Windows运行正常

1. Mac（Mono 环境）调用Close()超时核心原因 #

该问题本质是Mono与微软官方.NET Framework对WCF NetTcp双工通道的关闭逻辑实现差异导致：

• 你使用的是双工通道（DuplexChannelFactory），且客户端和服务端均开启了AutomaticSessionShutdown=true配置，该配置要求客户端调用Close()时，需要等待服务端返回会话关闭确认报文，完成双向会话的优雅关闭流程后才会结束关闭操作。
• Windows .NET Framework的NetTcp实现逻辑更宽松：如果检测到通道已无待处理消息，会直接发送TCP RST包终止连接，不需要等待额外的会话确认，因此关闭操作不会卡顿。
• Mono的NetTcp实现存在缺陷：严格按照TCP优雅关闭流程发送FIN包，但是没有正确识别/处理服务端返回的会话关闭确认报文，即使服务端已经感知到连接断开，Mono的WCF栈仍会一直阻塞等待确认信号，直到触发超时。

2. CloseTimeout配置不生效原因 #

这也是Mono WCF的已知实现差异：通过NetTcpBinding设置的CloseTimeout仅会作用于ChannelFactory本身，创建出来的客户端通道实例不会继承该超时配置，只有显式调用Close(TimeSpan timeout)重载方法时，传入的超时参数才会生效，该逻辑与.NET Framework默认继承绑定超时配置的行为不一致。

• 快速规避方案：直接将channelRef.Close()替换为显式传参的重载channelRef.Close(TimeSpan.FromSeconds(20))，你已经验证过该方式可让超时配置正常生效，超时后自动触发Abort逻辑，不会影响业务流程。
• 彻底解决超时方案：将客户端CallbackBehavior配置中的AutomaticSessionShutdown改为false，跳过双工会话的双向关闭确认流程，不需要等待服务端返回关闭确认即可直接关闭通道，该改动在绝大多数业务场景下无副作用。
• 兼容性优化方案：如果条件允许，可将Mac客户端的WCF逻辑迁移至.NET Core/.NET 5+的官方跨平台WCF客户端实现，其对NetTcp协议的兼容性远优于Mono的自研实现，可避免大量平台差异问题。
• 深度排查方案：可进一步过滤WCF NetTcp协议层的报文，确认服务端是否正确返回了WCF层面的会话关闭响应，验证Mono WCF栈是否存在报文解析异常。

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