AcceptAsync比Accept阻塞更难用，因其要求复用SocketAsyncEventArgs、手动管理缓冲区、显式SetBuffer、并在回调中立即重投递，漏任一环会导致连接丢弃或回调失效。
AcceptAsync 为什么比 Accept 阻塞更难用对
因为 AcceptAsync 不是“换汤不换药”的异步封装，它要求你**复用 SocketAsyncEventArgs 实例、手动管理缓冲区、显式调用 SetBuffer、且必须在完成回调中重新投递**。漏掉任一环，就会出现连接被静默丢弃、回调不触发、或 SocketError.OperationAborted 反复报错。
常见错误现象：AcceptAsync 返回 false（同步完成）但后续没收到连接；或返回 true 后永远等不到回调；或只接受一个连接就卡死。
-
SocketAsyncEventArgs必须在构造后调用AcceptSocket = null清空旧引用，否则下次 Accept 可能复用已关闭的 socket - 必须在每次回调开始时检查
e.SocketError == SocketError.Success，失败时不重投递 - 不能在回调里直接
e.AcceptSocket.Send(...)—— 此 socket 还未配置为非阻塞，首次 Send 可能阻塞线程池线程 - 推荐为每个监听 socket 单独分配一个
SocketAsyncEventArgs实例，避免多连接并发时状态污染
AcceptAsync 的正确投递循环怎么写
不是“调一次然后等”，而是“完成回调里立刻再调一次”，形成持续监听链。关键点在于：**所有错误分支都必须有明确出口，成功分支必须无条件重投递**。
private void StartAccept(SocketAsyncEventArgs acceptEventArg)
{
// 每次投递前重置关键字段
acceptEventArg.AcceptSocket = null;
acceptEventArg.SetBuffer(null, 0, 0); // Accept 不需要缓冲区，但必须显式设空
bool willRaiseEvent = _listenSocket.AcceptAsync(acceptEventArg);
if (!willRaiseEvent)
{
// 同步完成：立即处理
OnAcceptCompleted(acceptEventArg);
}
}
private void OnAcceptCompleted(SocketAsyncEventArgs e)
{
if (e.SocketError != SocketError.Success)
{
// 日志 + 不重投递（比如监听 socket 已关闭）
return;
}
// 处理新连接：例如把 e.AcceptSocket 交给另一个 SocketAsyncEventArgs 做 ReceiveAsync
ProcessNewClient(e.AcceptSocket);
// ⚠️ 关键：立刻发起下一次 AcceptAsync
StartAccept(e);
}
AcceptAsync 和 await AcceptAsync() 的区别在哪
别被名字误导：Socket.AcceptAsync() 是基于 SocketAsyncEventArgs 的底层异步模型，而 await socket.AcceptAsync()（.NET Core 2.1+）是包装后的 Task-based 异步方法，内部仍用同一套 IOCP 机制，但自动管理生命周期。
- 前者性能略高（零分配、无 Task 对象），适合每秒数千连接的服务器，但代码冗长易错
- 后者可直接
await，支持async/await流程控制，异常传播自然，适合大多数业务服务 - 二者不能混用同一个
Socket实例：调过AcceptAsync(SAEA)后，再调await AcceptAsync()会抛InvalidOperationException - 如果用
await AcceptAsync()，记得用ConfigureAwait(false)避免上下文捕获开销
为什么 AcceptAsync 接收的 Socket 默认是阻塞模式
这是 .NET 的明确设计：由 AcceptAsync 返回的 e.AcceptSocket **继承监听 socket 的 Blocking 属性**。而监听 socket 通常设为非阻塞（socket.Blocking = false），但新连接 socket 不会自动继承这个设置 —— 它默认是 Blocking = true。
后果很直接：你在回调里直接对 e.AcceptSocket 调用 Send 或 Receive，哪怕只发几个字节，也可能阻塞当前 IOCP 线程，拖垮整个连接池。
- 必须在
OnAcceptCompleted中立即将e.AcceptSocket.Blocking = false - 更推荐做法：立刻用另一个
SocketAsyncEventArgs对该 socket 调用ReceiveAsync，绕过阻塞风险 - 若要用
await e.AcceptSocket.ReceiveAsync(...)，也需先确保它非阻塞，否则 await 会假死
AcceptSocket 的阻塞状态和 SocketAsyncEventArgs 的重复使用安全。这两个点不出问题则风平浪静，一出就是连接堆积、CPU 空转、日志里满屏 OperationAborted。 
