overlapped i/o 是 windows 内核异步 i/o 机制，.net 的 async/await（如 readasync）在 windows 上底层依赖它，但由运行时自动封装管理；需显式使用 nativeoverlapped 的场景极少，仅限高性能自定义网络栈等互操作需求。
Overlapped I/O 是什么，和 .NET 的 async/await 有什么关系？
Overlapped I/O 是 Windows 内核提供的异步 I/O 基础机制，本质是让 ReadFile/WriteFile 等 API 在发起后立即返回，由系统在 I/O 完成时通过事件、APC 或 I/O 完成端口（IOCP）通知用户。.NET 的 async/await（如 FileStream.ReadAsync、Socket.ReceiveAsync）在 Windows 上底层大量依赖 Overlapped I/O —— 但你几乎不需要直接操作它。
关键点在于：.NET 运行时已封装好 Overlapped 的生命周期管理（分配、重用、回收）、内存 pinning、完成回调调度。手动调用 NativeOverlapped 或 ThreadPool.BindHandle 属于高级互操作场景，比如实现自定义高性能网络栈、对接非托管库、或绕过 .NET 的 FileStream 缓冲逻辑。
什么时候必须自己用 NativeOverlapped？
极少数情况需要显式控制 Overlapped 结构体，典型包括：
- 调用 Windows API 如
ReadFile、WSARecv等原生异步函数 - 复用同一块 native buffer 和 Overlapped 实例（避免 GC 压力），例如高吞吐服务器中固定大小的接收缓冲池
- 需要精确控制 completion key、APC 函数或与 IOCP 手动绑定
此时要特别注意：NativeOverlapped 必须 pin 住（用 GCHandle.Alloc(..., GCHandleType.Pinned)），且其内存布局需严格匹配 Windows 的 OVERLAPPED 结构；错误的偏移或未初始化字段会导致 ERROR_INVALID_PARAMETER 或静默失败。
FileStream.ReadAsync 底层真的用了 Overlapped 吗？
在 Windows 上，只要构造 FileStream 时传入了 FileOptions.Asynchronous（或使用 new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None, 4096, FileOptions.Asynchronous)），.NET 就会启用内核 Overlapped I/O 模式。否则，即使调用 ReadAsync，运行时也会退化为同步读 + 线程池线程模拟异步（即 “thread-pool fake async”）。
验证方式很简单：
var fs = new FileStream("test.dat", FileMode.Open, FileAccess.Read, FileShare.None, 4096, FileOptions.Asynchronous);
// 此时 ReadAsync 走真正的 Overlapped I/O
await fs.ReadAsync(buffer, CancellationToken.None);
漏掉 FileOptions.Asynchronous 是最常见性能陷阱 —— 表面是 async 方法，实际阻塞线程池线程，尤其在大文件随机读时放大延迟。
Socket 异步模型：Begin/End vs SocketAsyncEventArgs vs ValueTask
.NET 的 Socket 类提供了三层异步支持：
-
BeginReceive/EndReceive：基于Overlapped+ APC，兼容老代码，但每次调用都 new 委托和状态对象，GC 开销大 -
SocketAsyncEventArgs：可重用的对象池模式，内部持有NativeOverlapped*和 pinned buffer，性能最优，适合高频短连接场景 -
ReceiveAsync（返回ValueTask<int></int>）：现代推荐方式，底层仍走 IOCP，但由运行时自动管理 Overlapped 和 buffer 生命周期；注意它要求 socket 已启用IOControl(IOControlCode.EnableCircularQueues, ...)（.NET 5+ 默认开启）
混用这三者可能引发竞争：比如一个 SocketAsyncEventArgs 正在挂起等待时，又调用 ReceiveAsync，会导致 InvalidOperationException：“The I/O operation has been aborted because of either a thread exit or an application request.”
Overlapped I/O 的复杂性全藏在细节里：buffer pinning 是否持续、completion callback 在哪个线程执行、IOCP 关联是否正确、native handle 是否被提前关闭。.NET 的 async/await 把这些压平了，但压不平的是你对“真正异步”的理解边界 —— 一旦离开托管抽象，就得亲手处理每个 NativeOverlapped 的 EventHandle 和 InternalHigh 字段。
