C#中Socket.Disconnect(true)的作用是什么？是否能带来性能提升？

1. 关于“套接字复用”的定义差异 #

首先要区分.NET Framework和.NET Core/.NET 5+的不同实现逻辑：

• .NET Framework 时代的Disconnect(true)是直接调用Winsock原生的DisconnectEx接口，传入TF_REUSE_SOCKET标志，此时确实会复用同一个操作系统级的套接字句柄，开发者可以直接调用Connect方法复用这个Socket对象连接新的端点，省去了创建新套接字的系统开销，是真正的底层句柄复用。
• 你看到的.NET 5源码逻辑是官方为了跨平台兼容性做的重构：由于不同操作系统（Windows/Linux/macOS）的套接字复用规则差异极大，比如Linux下TCP套接字断开后存在TIME_WAIT状态，无法直接复用同一句柄连接新端点，跨平台统一原生复用逻辑的成本极高，因此微软调整了实现逻辑。

2. .NET 5+中Disconnect(true)的实际作用 #

你观察到的reuseSocket=true时调用ReplaceHandle创建新套接字句柄的逻辑完全正确，此时的“复用”已经不是底层句柄复用，而是Socket对象层面的配置复用：

• 调用Disconnect(true)后，原Socket对象的所有配置（发送/接收缓冲区大小、KeepAlive参数、TTL、SocketOption设置等）都会被自动复制到新创建的底层句柄上，开发者不需要再手动重新设置一遍所有参数。
• 对.NET Framework迁移过来的老代码做了行为兼容：原有基于Disconnect(true)实现的Socket对象复用逻辑不需要修改即可运行，不需要调整上层代码的池化、调用流程。

3. 是否有性能提升？ #

如果你的预期是通过复用底层套接字句柄减少系统调用开销，那么在.NET 5+中Disconnect(true)确实无法达到这个效果，底层创建新句柄的开销和直接new一个新Socket对象基本一致，甚至因为要复制原有配置会有极微小的额外开销。
但它仍然有实际工程意义：

• 减少了同配置Socket的重复初始化代码，降低手动设置SocketOption出错的概率
• 保证了老版本代码的向后兼容性，不需要重构上层调用逻辑
  如果你的目标是做连接池降低连接开销，更推荐直接池化已经建立完成的TCP连接，而不是池化处于断开状态的Socket对象。

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